[Bug other/44032] internals documentation is not legally safe to use

[egallager at gcc dot gnu.org]

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

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> Richard says the FSF doesn't object to combinations of GFDL code from the
> manual with GPL code from the source and that we can put a statement to this
> effect in the internals manual.

So, now that RMS is out at the FSF... does what he have to say on this issue
even matter any longer, or do we have to ask someone else at the FSF now?

[Bug fortran/91959] [8/9/10 Regression] Accepts invalid variable declaration %x

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.3 |10.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch does not apply cleanly to 9-branch.  Fixed on trunk.  Closing.

[Bug fortran/91943] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/91942] ICE in match_vtag, at fortran/io.c:1485

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch.  Closing.

[Bug fortran/91942] ICE in match_vtag, at fortran/io.c:1485

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Oct  5 04:05:05 2019
New Revision: 276620

URL: https://gcc.gnu.org/viewcvs?rev=276620=gcc=rev
Log:
2019-10-04  Steven G. Kargl  

PR fortran/91942
* io.c (match_vtag): Check for non-NULL result->symtree.
(match_out_tag): Check for invalid constant due to inquiry parameter.
(match_filepos): Instead of a syntax error, go to cleanup to get better
error messages.

2019-10-04  Steven G. Kargl  

PR fortran/91942
* gfortran.dg/pr91587.f90: Update dg-error regex.
* gfortran.dg/pr91942.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91942.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/io.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91587.f90

[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch. Closing.

[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Oct  5 03:55:05 2019
New Revision: 276619

URL: https://gcc.gnu.org/viewcvs?rev=276619=gcc=rev
Log:
2019-10-04  Steven G. Kargl  

PR fortran/91785
* primary.c (gfc_match_varspec): Ensure an inquiry parameter has
it locus set.

2019-10-04  Steven G. Kargl  

PR fortran/91785
* gfortran.dg/pr91785.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91785.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/primary.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91784] ICE in gfc_real2complex, at fortran/arith.c:2208

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.3 |10.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch did not apply cleanly to 9-branch.  Closing as fixed.

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

[kargl at gcc dot gnu.org]

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

Bug 42607 Summary: add information about how to compile a module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42607

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug fortran/42607] add information about how to compile a module

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #16 from kargl at gcc dot gnu.org ---
Closing from lack of interest from anyone that seemed to care.

[Bug fortran/42118] Slow forall

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
Fortran 2018 has declared FORALL to be an obsolescent feature.
I doubt that anyone will ever try to improve the performance
of FORALL, because the next standard is likely to delete it.

I think that this bug can be closed with WONTFIX or WORKSFORME.

[Bug fortran/47054] Compilation error when cray pointers are declared in both host and internal subroutines

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.3

[Bug rtl-optimization/91994] [10 Regression] r276327 breaks -mvzeroupper

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[10 Regression] r276327 |[10 Regression] r276327
   |miscompiled 557.xz_r in |breaks -mvzeroupper
   |SPEC CPU 2017   |

--- Comment #5 from H.J. Lu  ---
[hjl@gnu-skx-1 gcc]$ cat bad.c
#include 
#include 

__m256i x1, x2, x3;

__attribute__ ((noinline))
static void
foo (void)
{
  x1 = x2;
}

void
bar (void)
{
  __m256i x = x1;
  foo ();
  x3 = x;
}

__attribute__ ((noinline))
int
main (void)
{
  __m256i x = _mm256_set1_epi8 (3);
  x1 = x;
  bar ();
  if (__builtin_memcmp (, , sizeof (x)))
abort ();
  return 0;
}
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -march=skylake  -O2  bad.c 
./a[hjl@gnu-skx-1 gcc]$ ./a.out 
Aborted
[hjl@gnu-skx-1 gcc]$ ./xgcc -B./ -march=skylake  -O2  bad.c -S
[hjl@gnu-skx-1 gcc]$ cat bad.s
.file   "bad.c"
.text
.p2align 4
.type   foo, @function
foo:
.LFB5339:
.cfi_startproc
vmovdqa x2(%rip), %ymm0
vmovdqa %ymm0, x1(%rip)
vzeroupper <<< Clobber the upper bits of YMM1.
ret
.cfi_endproc
.LFE5339:
.size   foo, .-foo
.p2align 4
.globl  bar
.type   bar, @function
bar:
.LFB5340:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
vmovdqa x1(%rip), %ymm1
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
callfoo
vmovdqa %ymm1, x3(%rip)
vzeroupper
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE5340:
.size   bar, .-bar
.section.text.startup,"ax",@progbits
.p2align 4
.globl  main
.type   main, @function
main:
.LFB5341:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movabsq $217020518514230019, %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
subq$32, %rsp
vmovdqa .LC0(%rip), %ymm1
vmovdqa %ymm1, (%rsp)
vmovdqa %ymm1, x1(%rip)
callfoo
vmovdqa %ymm1, x3(%rip)
movqx3+8(%rip), %rdx
xorq(%rsp), %rax
xorq8(%rsp), %rdx
orq %rax, %rdx
jne .L6
movqx3+24(%rip), %rdx
movqx3+16(%rip), %rax
xorq24(%rsp), %rdx
xorq16(%rsp), %rax
orq %rax, %rdx
je  .L9
.L6:
vzeroupper
callabort
.p2align 4,,10
.p2align 3
.L9:
xorl%eax, %eax
vzeroupper
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE5341:
.size   main, .-main
.comm   x3,32,32
.comm   x2,32,32
.comm   x1,32,32
.section.rodata.cst32,"aM",@progbits,32
.align 32
.LC0:
.quad   217020518514230019
.quad   217020518514230019
.quad   217020518514230019
.quad   217020518514230019
.ident  "GCC: (GNU) 10.0.0 20191003 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skx-1 gcc]$

[Bug c/82752] Support %OB, %Ob strftime formats

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #3 from Joseph S. Myers  ---
Implemented for GCC 10.

[Bug c/82752] Support %OB, %Ob strftime formats

[jsm28 at gcc dot gnu.org]

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

--- Comment #2 from Joseph S. Myers  ---
Author: jsm28
Date: Fri Oct  4 21:56:14 2019
New Revision: 276605

URL: https://gcc.gnu.org/viewcvs?rev=276605=gcc=rev
Log:
Add strftime format checking support for C2x %OB and %Ob (bug 82752).

C2x adds strftime %OB and %Ob formats, for alternative forms of month
names (for mainly Slavic languages where a month name on its own is
declined differently from a month name together with a date within
that month).  This patch adds corresponding format checking support.
(glibc support for these formats was added in glibc 2.27.)

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

PR c/82752
gcc/c-family:
* c-format.c (C_STD_VER): Handle C2x.
(C_STD_NAME): Likewise.
(strftime_flag_specs): Add 'O' modifier with 'p' flag.
(time_char_table): Use separate entry for 'B' and 'b', with 'O'
modifier allowed and 'p' flag.
* c-format.h (enum format_std_version): Add STD_C2X.
(struct format_char_info): Mention 'p' in comment on flags2.

gcc/testsuite:
* gcc.dg/format/c2x-strftime-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/format/c2x-strftime-1.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/c-family/c-format.h
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/91994] [10 Regression] r276327 miscompiled 557.xz_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to H.J. Lu from comment #3)
> lzma_sha256_update in sha256.c is miscompiled with -O3 -march=skylake.
> Correct code:
> 
> L42:
> ...
> vpshufb %ymm7, %ymm1, %ymm0
> vmovdqa %ymm0, (%rsp)
> leaq64(%r13), %rdi
> vpshufb %ymm7, %ymm2, %ymm0
> movq%rsp, %rsi
> vmovdqa %ymm0, 32(%rsp)
> calltransform
> vmovdqa .LC0(%rip), %ymm7  <<< This is missing.
> .L49:
> testq   %rbx, %rbx
> je  .L69
> .L50:
> ...
> cmpl$32, %ecx
> jb  .L65

vzeroupper clears the upper bits of %ymm7 when transform returns.  If
-mzeroupper is used, upper bits of vector registers are clobbered upon
callee return if any YMM/ZMM registers are used in callee.

[Bug middle-end/91977] missing -Wstringop-overflow on memcpy into a pointer plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Patch committed in r276603.

[Bug middle-end/91977] missing -Wstringop-overflow on memcpy into a pointer plus offset

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Fri Oct  4 21:29:41 2019
New Revision: 276603

URL: https://gcc.gnu.org/viewcvs?rev=276603=gcc=rev
Log:
PR middle-end/91977 - missing -Wstringop-overflow on memcpy into a pointer plus
offset

gcc/ChangeLog:

PR middle-end/91977
* tree-ssa-strlen.c (count_nonzero_bytes): Handle assignments with
MEM_REF right operand.  Avoid failing for MEM_REF assignments from
uninitialized objects.

gcc/testsuite/ChangeLog:

PR middle-end/91977
* gcc.dg/Wstringop-overflow-18.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-18.c
trunk/gcc/tree-ssa-strlen.c

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

[msebor at gcc dot gnu.org]

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

Bug 91977 Summary: missing -Wstringop-overflow on memcpy into a pointer plus 
offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91977

   What|Removed |Added

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

[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name

[fuchedzhy at google dot com]

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

--- Comment #5 from Gregory Fuchedzhy  ---
(In reply to Eric Gallager from comment #3)
> *** Bug 91998 has been marked as a duplicate of this bug. ***

Not exactly a duplicate, but related.
Clang implemented an additional __FILE_NAME__ macro.

See:
https://reviews.llvm.org/D61756
https://reviews.llvm.org/D17741

[Bug target/91967] gtest from google generates incorrect assembly code on x86 solaris

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Not a GCC bug so closing.

[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-04
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
Taking dup as confirmation

[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||fuchedzhy at google dot com

--- Comment #3 from Eric Gallager  ---
*** Bug 91998 has been marked as a duplicate of this bug. ***

[Bug c/91998] Add a __FILE_NAME__ macro

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
dup of bug 82176

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

[Bug c/91998] New: Add a __FILE_NAME__ macro

[fuchedzhy at google dot com]

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

Bug ID: 91998
   Summary: Add a __FILE_NAME__ macro
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fuchedzhy at google dot com
  Target Milestone: ---

It would be handy to have macro similar to __FILE__ but expanding to source
*base* file name only.
It might be useful for application logs and asserts, especially on embedded
systems, where we don't want to do string searches in runtime and don't want to
store full paths (which might be very long) in the binary.

Clang added such macro recently, see:
https://reviews.llvm.org/D61756
https://reviews.llvm.org/D17741

[Bug rtl-optimization/91994] [10 Regression] r276327 miscompiled 557.xz_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
lzma_sha256_update in sha256.c is miscompiled with -O3 -march=skylake.
Correct code:

L42:
...
vpshufb %ymm7, %ymm1, %ymm0
vmovdqa %ymm0, (%rsp)
leaq64(%r13), %rdi
vpshufb %ymm7, %ymm2, %ymm0
movq%rsp, %rsi
vmovdqa %ymm0, 32(%rsp)
calltransform
vmovdqa .LC0(%rip), %ymm7  <<< This is missing.
.L49:
testq   %rbx, %rbx
je  .L69
.L50:
...
cmpl$32, %ecx
jb  .L65

[Bug libfortran/91543] [10 Regression] nf failure ( Handling stack overflow more sensibly

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Priority|P3  |P4
Version|unknown |10.0
   Target Milestone|--- |10.0
Summary|Handling stack overflow |[10 Regression] nf failure
   |more sensibly   |( Handling stack overflow
   ||more sensibly

--- Comment #4 from Thomas Koenig  ---
The nf failure is a regression in itself, so we should mark it as such,
and we should definitely try to fix this before gcc 10 comes out.

[Bug libstdc++/91997] New: pretty printers: The __node_type type alias _Hashtable is not available

[rafael at espindo dot la]

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

Bug ID: 91997
   Summary: pretty printers: The __node_type type alias _Hashtable
is not available
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

At least when compiling with optimizations with

gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)

the debug info doesn't include the type alias

 using __node_type = __detail::_Hash_node<_Value, __hash_cached::value>

Which causes the pretty printer to fail with

-
Traceback (most recent call last):
  File "/home/espindola/scylla/gdb-printers/libstdcxx/v6/printers.py", line
966, in children
data = self.flatten (imap (self.format_one, StdHashtableIterator
(self.hashtable(
  File "/home/espindola/scylla/gdb-printers/libstdcxx/v6/printers.py", line
889, in __init__
self.node_type = find_type(hash.type, '__node_type').pointer()
  File "/home/espindola/scylla/gdb-printers/libstdcxx/v6/printers.py", line 97,
in find_type
field = typ.fields()[0]
IndexError: list index out of range
-

To work around that the pretty printer should reconstruct the type.
The best I was able to come up with was 

-self.node_type = find_type(hash.type, '__node_type').pointer()
+pair_name = hash.type.template_argument(1).name
+traits_type = hash.type.template_argument(9)
+cached = str(traits_type.template_argument(0)).lower()
+node_name = '::std::__detail::_Hash_node<%s,%s>' % (pair_name, cached)
+self.node_type = gdb.lookup_type(node_name).pointer()

[Bug tree-optimization/91996] fold non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization
   Last reconfirmed||2019-10-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Blocks||83819
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
This enhancement is what the FIXME in tree-ssa-strlen.c refers to:

static bool
count_nonzero_bytes (tree exp, unsigned HOST_WIDE_INT offset,
 unsigned HOST_WIDE_INT nbytes,
 unsigned lenrange[3], bool *nulterm,
 bool *allnul, bool *allnonnul, ssa_name_limit_t )
{
  int idx = get_stridx (exp);
  if (idx > 0)
{
  strinfo *si = get_strinfo (idx);
  /* FIXME: Handle non-constant lengths in some range.  */
  if (!si || !tree_fits_shwi_p (si->nonzero_chars))
return false;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/91996] New: fold non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

Bug ID: 91996
   Summary: fold non-constant strlen relational expressions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Now that the strlen pass is integrated with EVRP it's become possible to make
use of the EVRP ranges to fold even some relational expressions involving
non-constant strlen values.  For example, in the test case below, since a's
length is known to be at least 7, copies of its first N characters must be at
least as long as MIN (N, strlen (a)].

$ cat b.c && gcc -S -O2 -Wall -fdump-tree-optimized=/dev/stdout b.c
extern char a[32], b[32];

void f (void)
{
  if (__builtin_strlen (a) < 7)
return;

  __builtin_memcpy (b, a, sizeof b);

  if (__builtin_strlen (b) < 7)   // can be folded to false
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1926, cgraph_uid=1, symbol_order=0)

Removing basic block 6
Removing basic block 7
f ()
{
  long unsigned int _1;
  long unsigned int _2;

   [local count: 1073741824]:
  _1 = __builtin_strlen ();
  if (_1 <= 6)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669605]:
  MEM  [(char * {ref-all})] = MEM 
[(char * {ref-all})];
  _2 = __builtin_strlen ();
  if (_2 <= 6)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741829]:
  return;

}

[Bug rtl-optimization/91994] [10 Regression] r276327 miscompiled 557.xz_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
liblzma/check/sha256.c is miscompiled.

[Bug target/85401] segfault building code for VAX

[coypu at sdf dot org]

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

coypu  changed:

   What|Removed |Added

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

--- Comment #9 from coypu  ---
Fixed, also the very related second failure (that creduce managed to find, when
reducing this test case).
https://gcc.gnu.org/viewcvs/gcc?view=revision=276587

[Bug fortran/91801] ICE in gfc_simplify_reshape, at fortran/simplify.c:6733

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #1)
> Should be easy to fix.

Likely, all of the gcc_assert()'s in gfc_simplify_reshape
should be gfc_error()'s.  This patch fixes the ICE for
this PR. (Watch for cut-n-paste tab corruption).

Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 276593)
+++ gcc/fortran/simplify.c  (working copy)
@@ -6762,7 +6762,15 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shap

  gfc_extract_int (e, [i]);

- gcc_assert (order[i] >= 1 && order[i] <= rank);
+ if (order[i] < 1 || order[i] > rank)
+   {
+ gfc_error ("Element with a value of %d in ORDER at %L must be "
+"in the range [1, ..., %d] for the RESHAPE intrinsic "
+"near %L", order[i], _exp->where, rank,
+_exp->where);
+ return _bad_expr;
+   }
+
  order[i]--;
  if (x[order[i]] != 0)
{

[Bug preprocessor/91991] ICE in linemap_macro_map_lookup when LTO-building SQLite after r275402

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #1 from Nathan Sidwell  ---
fixed r276596.

[Bug preprocessor/91991] ICE in linemap_macro_map_lookup when LTO-building SQLite after r275402

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Fri Oct  4 19:08:09 2019
New Revision: 276596

URL: https://gcc.gnu.org/viewcvs?rev=276596=gcc=rev
Log:
[preprocessor/91991] column location overflow

https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00371.html
PR preprocessor/91991
* line-map.c (linemap_line_start): Clear max_column_hint if we run
out of locations.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug ada/91995] gnat miscompilation and bootstrap failure on m68k-linux

[mikpelinux at gmail dot com]

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

--- Comment #1 from Mikael Pettersson  ---
Created attachment 46997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46997=edit
Workaround patch

Patch which avoids the miscompilation by changing the source code to replace
these formal-with-defaults with plain formals without defaults.  This is merely
a workaround, I'm not suggesting this as the proper fix for upstream.

[Bug ada/91995] New: gnat miscompilation and bootstrap failure on m68k-linux

[mikpelinux at gmail dot com]

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

Bug ID: 91995
   Summary: gnat miscompilation and bootstrap failure on
m68k-linux
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to bootstrap gnat on m68k-linux fails due to a SEGV in stage3:

/mnt/scratch/objdir10/./prev-gcc/xgcc -B/mnt/scratch/objdir10/./prev-gcc/
-B/home/mikpe/pkgs/linux-m68k/gcc-10.0/m68k-unknown-linux-gnu/bin/
-B/home/mikpe/pkgs/linux-m68k/gcc-10.0/m68k-unknown-linux-gnu/bin/
-B/home/mikpe/pkgs/linux-m68k/gcc-10.0/m68k-unknown-linux-gnu/lib/ -isystem
/home/mikpe/pkgs/linux-m68k/gcc-10.0/m68k-unknown-linux-gnu/include -isystem
/home/mikpe/pkgs/linux-m68k/gcc-10.0/m68k-unknown-linux-gnu/sys-include  
-fchecking=1 -c -g -O2 -fchecking=1  -gnatpg  -W -Wall -g -O1 -fno-inline \
 -nostdinc -I- -I. -Iada/generated -Iada -I/mnt/scratch/gcc-10-20190915/gcc/ada
-I/mnt/scratch/gcc-10-20190915/gcc/ada/gcc-interface -Iada/libgnat
-I/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-except.adb -o
ada/libgnat/a-except.o
+===GNAT BUG DETECTED==+
| 10.0.0 20190915 (experimental) (m68k-unknown-linux-gnu) Storage_Error stack
overflow or erroneous memory access|
| Error detected at a-exexda.adb:625:13|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/system.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-except.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-except.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/ada.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-parame.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-stalib.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-unccon.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-traent.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-except.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-excdeb.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-soflin.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-secsta.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-stoele.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-stache.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-wchcon.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-wchstw.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-traceb.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-trasym.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-exctab.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-excpol.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-excach.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-exexda.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-exexpr.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-uncdea.ads
ada/libgnat/s-excmac.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-exextr.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-elchha.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-imgint.ads
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/a-exstat.adb
/mnt/scratch/gcc-10-20190915/gcc/ada/libgnat/s-stoele.adb

compilation abandoned
make[3]: *** [ada/libgnat/a-except.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir10/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir10'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir10'
make: *** [bootstrap] Error 2

Running that under gdb shows a NULL pointer dereference:

Program received signal SIGSEGV, Segmentation fault.
0x8006bbdc in build_unary_op(tree_code, tree_node*, tree_node*) ()

(gdb) print/x $pc
$1 = 0x8006bbdc
(gdb) disassemble 0x8006bbd0, 0x8006bbf0 
Dump of assembler code from 0x8006bbd0 to 0x8006bbf0:
   0x8006bbd0 <_Z14build_unary_op9tree_codeP9tree_nodeS1_+1030>:jsr
0x805582d8 <_Z27build_fold_indirect_ref_locjP9tree_node>
   0x8006bbd6 <_Z14build_unary_op9tree_codeP9tree_nodeS1_+1036>:moveal
%a0,%a2
   0x8006bbd8 <_Z14build_unary_op9tree_codeP9tree_nodeS1_+1038>:moveal
%a5@(8),%a0
=> 0x8006bbdc 

[Bug rtl-optimization/91994] [10 Regression] r276327 miscompiled 557.xz_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-04
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
liblzma/lzma/lzma_encoder.c and/or liblzma/check/sha256.c are miscompiled.
The good one has

callq  0 
cmp%r13,%r14
vmovdqa XXX(%rip),%ymm0
jne
...
vmovdqu %ymm0,XXX(%rbx)

The bad one has

callq  0 
cmp%r13,%r14
jne
vmovdqu %ymm0,XXX(%rbx)

length_update_prices clobbers %ymm0, which isn't restored after call.

[Bug rtl-optimization/91994] New: [10 Regression] r276327 miscompiled 557.xz_r in SPEC CPU 2017

[hjl.tools at gmail dot com]

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

Bug ID: 91994
   Summary: [10 Regression] r276327 miscompiled 557.xz_r in SPEC
CPU 2017
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rdsandiford at googlemail dot com
  Target Milestone: ---

On x86-64, r276327 miscompiled 557.xz_r in SPEC CPU 2017 with

-fno-unsafe-math-optimizations -mfpmath=sse  -march=skylake   -Ofast
-funroll-loops

hjl@gnu-skx-1 run_peak_refrate_gcc_native-m64.]$ cat
cpu2006docs.tar-250-6e.out.mis
0011:  Uncompressed data 262144000 bytes in length
   Decompression decoder error: Compressed data is corrupt (code 9)
   ^
0012:  Uncompressed data compared correctly
   Uncompressed data 262144000 bytes in length
 ^
0013:  Tested 250 MiB buffer: OK!
   Uncompressed data compared correctly
   ^
'cpu2006docs.tar-250-6e.out' long
[hjl@gnu-skx-1 run_peak_refrate_gcc_native-m64.]$

[Bug c++/91993] New: Spurious -Wconversion warning with -fsanitize=undefined

[TonyELewis at hotmail dot com]

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

Bug ID: 91993
   Summary: Spurious -Wconversion warning with
-fsanitize=undefined
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TonyELewis at hotmail dot com
  Target Milestone: ---

Compiling:

auto fn( const unsigned char ,
 const unsigned char ,
 const unsigned char  ) {
   return static_cast(
  static_cast(
   a << 1U
  )
  |
  b
  )
  |
  c;
}

...with:

g++ -fsanitize=undefined -Werror -Wconversion -std=c++17 -fsyntax-only a.cpp

...I get:

a.cpp: In function ‘auto fn(const unsigned char&, const unsigned char&, const
unsigned char&)’:
a.cpp:4:11: error: conversion from ‘int’ to ‘unsigned char’ may change value
[-Werror=conversion]
4 |return static_cast(
  |   ^~~
5 |   static_cast(
  |   ~~~
6 |a << 1U
  |~~~
7 |   )
  |   ~
8 |   |
  |   ~
9 |   b
  |   ~
   10 |   )
  |   ~
cc1plus: all warnings being treated as errors

...which I think is spurious. Interestingly, the warning goes away if I remove
`-fsanitize=undefined` (and I can't persuade clang-tidy or `clang -Weverything`
to complain about it).

I'm seeing this on g++ (GCC) 9.2.0 (Ubuntu 18.04.3 LTS, Linux
4.15.0-65-generic) but I've registered it as 10.0 because I see the same
behaviour on GCC master on Godbolt.

The closest to an active duplicate that I can see is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91179 but that doesn't mention
`-fsanitize=undefined` so I suspect that's different.

[Bug go/91992] gcc/testsuite/go/index0-out.x SEGV and spinlock during testsuite run

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  ---
On aarch64, I see

*** stack smashing detected ***:  terminated

[Bug go/91992] gcc/testsuite/go/index0-out.x SEGV and spinlock during testsuite run

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
Created attachment 46996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46996=edit
index0-out.go

[Bug go/91992] gcc/testsuite/go/index0-out.x SEGV and spinlock during testsuite run

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
I don't know what is happening here.

The way this test works is that the file gcc/testsuite/go.test/test/index.go
and gcc/testsuite/go.test/test/index0.go are compiled together, producing a
file index0-out.go.  Then that file is compiled and run.  It is expected to
exit 0 with no output.  When I run that file on my laptop, it takes 0.2
seconds.  Clearly something is going very wrong on your systems.

I've attached that file.  You should be able to compile it using gccgo as
usual.  Perhaps you can use that to debug where it is failing.

[Bug go/91992] gcc/testsuite/go/index0-out.x SEGV and spinlock during testsuite run

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
There is also bug 87589 for other index0-out.x failures that don't appear
directly related to this problem.

[Bug go/91992] New: gcc/testsuite/go/index0-out.x SEGV and spinlock during testsuite run

[msebor at gcc dot gnu.org]

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

Bug ID: 91992
   Summary: gcc/testsuite/go/index0-out.x SEGV and spinlock during
testsuite run
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: msebor at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

As discussed in https://gcc.gnu.org/ml/gcc/2019-09/msg00152.html,
gcc/testsuite/go/index0-out.x spins indefinitely during the testsuite run on
x86_64-linux running Fedora 30, preventing it from completing.  One set of
backtraces was reported here:
https://gcc.gnu.org/ml/gcc/2019-09/msg00185.html

The two stack traces I have seen are in my recent build are:

Thread 1 "index0-out.x" received signal SIGSEGV, Segmentation fault.
merge_dynamic_blocks (b=0x1680600, a=0x80)
at /ssd/test/src/gcc/91977/libgcc/generic-morestack.c:420
420   for (pp = >next; *pp != NULL; pp = &(*pp)->next)
(gdb) bt
#0  merge_dynamic_blocks (b=0x1680600, a=0x80)
at /ssd/test/src/gcc/91977/libgcc/generic-morestack.c:420
#1  __morestack_release_segments (free_dynamic=, 
pp=)
at /ssd/test/src/gcc/91977/libgcc/generic-morestack.c:455
#2  __generic_morestack (pframe_size=0x72d485a0, old_stack=0x72d485c0, 
param_size=0) at /ssd/test/src/gcc/91977/libgcc/generic-morestack.c:546
#3  0x777934d8 in __morestack ()
at /ssd/test/src/gcc/91977/libgcc/config/i386/morestack.S:512
#4  0x772023b0 in __go_get_backtrace_state ()
at /ssd/test/src/gcc/91977/libgo/runtime/go-caller.c:107
#5  0x77202b9e in runtime_callers (skip=skip@entry=2, 
locbuf=locbuf@entry=0xc46948, m=m@entry=32, 
keep_thunks=keep_thunks@entry=false)
at /ssd/test/src/gcc/91977/libgo/runtime/go-callers.c:208
#6  0x7767fcee in runtime.callers (locbuf=..., locbuf=..., skip=1)
at /ssd/test/src/gcc/91977/libgo/go/runtime/traceback_gccgo.go:60
#7  runtime.mcommoninit (mp=mp@entry=0xc46800)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:614
#8  0x77689eaa in runtime.allocm (_p_=_p_@entry=0xc1c500, 
fn=, allocatestack=allocatestack@entry=false)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:1511
#9  0x7768a348 in runtime.newm (
fn=fn@entry=0x77b58fb8 , 
_p_=_p_@entry=0xc1c500)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:1818
#10 0x7768a684 in runtime.startm (_p_=0xc1c500, _p_@entry=0x0, 
spinning=spinning@entry=true)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:1967
#11 0x7768b67c in runtime.wakep ()
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:2048
#12 0x7768df88 in __go_go (fn=fn@entry=140737344200784, 
arg=arg@entry=0x0) at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:3232
#13 0x7764f148 in runtime.runtime..init3 ()
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:275
#14 0x7769b955 in runtime..import ()
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:273
#15 0x0055c10a in main.init () at ./index0-out.go:5
#16 0x0055c7fc in __morestack ()
at /ssd/test/src/gcc/91977/libgcc/config/i386/morestack.S:546
#17 0x7768e2df in runtime.main (p.0=)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:218
#18 0x77688ee8 in runtime.kickoff ()
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:1213
#19 0x in ?? ()

and

Thread 1 "index0-out.x" received signal SIGSEGV, Segmentation fault.
0x77fdbfa2 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x77fdbfa2 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#1  0x77fdcbcf in _dl_lookup_symbol_x ()
   from /lib64/ld-linux-x86-64.so.2
#2  0x77fe1544 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#3  0x77fe829e in _dl_runtime_resolve_xsavec ()
   from /lib64/ld-linux-x86-64.so.2
#4  0x772023b0 in __go_get_backtrace_state ()
at /ssd/test/src/gcc/91977/libgo/runtime/go-caller.c:107
#5  0x77202b9e in runtime_callers (skip=skip@entry=2, 
locbuf=locbuf@entry=0xc46948, m=m@entry=32, 
keep_thunks=keep_thunks@entry=false)
at /ssd/test/src/gcc/91977/libgo/runtime/go-callers.c:208
#6  0x7767fcee in runtime.callers (locbuf=..., locbuf=..., skip=1)
at /ssd/test/src/gcc/91977/libgo/go/runtime/traceback_gccgo.go:60
#7  runtime.mcommoninit (mp=mp@entry=0xc46800)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:614
#8  0x77689eaa in runtime.allocm (_p_=_p_@entry=0xc1c500, 
fn=, allocatestack=allocatestack@entry=false)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:1511
#9  0x7768a348 in runtime.newm (
fn=fn@entry=0x77b58fb8 , 
_p_=_p_@entry=0xc1c500)
at /ssd/test/src/gcc/91977/libgo/go/runtime/proc.go:1818
#10 

[Bug c/91985] Unsupported DFP not diagnosed with constants or built-in functions

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Author: jsm28
Date: Fri Oct  4 16:08:06 2019
New Revision: 276588

URL: https://gcc.gnu.org/viewcvs?rev=276588=gcc=rev
Log:
Mark C2x built-in functions as such.

Various built-in functions that GCC has as extensions are now standard
functions in C2x.  This patch adds DEF_C2X_BUILTIN and uses it to mark
them as such.  Some of the so-marked functions were previously
DEF_EXT_LIB_BUILTIN, while some DFP ones were DEF_GCC_BUILTIN
(i.e. __builtin_* only); both sets become DEF_C2X_BUILTIN.  This in
turn requires flag_isoc2x to be defined in various front ends using
builtins.def.

As the semantics of the built-in functions should already be tested,
the tests added only verify that they are declared in C2x mode but not
in C11 mode.  The test of DFP built-in functions being declared for
C2x goes in gcc.dg/dfp/, as while such built-in functions currently
don't depend on whether DFP is supported, that looks like a bug to me
(see bug 91985), so it seems best for the tests not to depend on
exactly how that bug might be fixed.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc:
* builtins.def (DEF_C2X_BUILTIN): New macro.
(exp10, exp10f, exp10l, fabsd32, fabsd64, fabsd128, nand32)
(nand64, nand128, roundeven, roundevenf, roundevenl, strdup)
(strndup): Use DEF_C2X_BUILTIN.
* coretypes.h (enum function_class): Add function_c2x_misc.

gcc/ada:
* gcc-interface/utils.c (flag_isoc2x): New variable.

gcc/brig:
* brig-lang.c (flag_isoc2x): New variable.

gcc/lto:
* lto-lang.c (flag_isoc2x): New variable.

gcc/testsuite:
* gcc.dg/c11-builtins-1.c, gcc.dg/c2x-builtins-1.c,
gcc.dg/dfp/c2x-builtins-dfp-1.c: New tests.

Added:
trunk/gcc/testsuite/gcc.dg/c11-builtins-1.c
trunk/gcc/testsuite/gcc.dg/c2x-builtins-1.c
trunk/gcc/testsuite/gcc.dg/dfp/c2x-builtins-dfp-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/utils.c
trunk/gcc/brig/ChangeLog
trunk/gcc/brig/brig-lang.c
trunk/gcc/builtins.def
trunk/gcc/coretypes.h
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-lang.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #7 from Jonathan Wakely  ---
Fixed on trunk.

[Bug libstdc++/81091] libstdc++ not built with large file support

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk so far. This should be OK to backport too, but I'll let it bake
on trunk for a while.

[Bug libstdc++/81091] libstdc++ not built with large file support

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Fri Oct  4 15:08:23 2019
New Revision: 276585

URL: https://gcc.gnu.org/viewcvs?rev=276585=gcc=rev
Log:
Build filesystem library with large file support

Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to
be used by default. We do not want to define those macros in the
public headers that users include. The values of the macros are copied
to a separate file that is only included by the filesystem sources
during the build, and then the macros in  are renamed
so that they don't have any effect in user code including our headers.

Also use larger type for result of filesystem::file_size to avoid
truncation of large values on 32-bit systems (PR 91947).

PR libstdc++/81091
PR libstdc++/91947
* configure.ac: Use AC_SYS_LARGEFILE to enable 64-bit file APIs.
* config.h.in: Regenerate:
* configure: Regenerate:
* include/Makefile.am (${host_builddir}/largefile-config.h): New
target to generate config header for filesystem library.
(${host_builddir}/c++config.h): Rename macros for large file support.
* include/Makefile.in: Regenerate.
* src/c++17/fs_dir.cc: Include new config header.
* src/c++17/fs_ops.cc: Likewise.
(filesystem::file_size): Use uintmax_t for size.
* src/filesystem/dir.cc: Include new config header.
* src/filesystem/ops.cc: Likewise.
(experimental::filesystem::file_size): Use uintmax_t for size.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/src/c++17/fs_dir.cc
trunk/libstdc++-v3/src/c++17/fs_ops.cc
trunk/libstdc++-v3/src/filesystem/dir.cc
trunk/libstdc++-v3/src/filesystem/ops.cc

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri Oct  4 15:08:23 2019
New Revision: 276585

URL: https://gcc.gnu.org/viewcvs?rev=276585=gcc=rev
Log:
Build filesystem library with large file support

Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to
be used by default. We do not want to define those macros in the
public headers that users include. The values of the macros are copied
to a separate file that is only included by the filesystem sources
during the build, and then the macros in  are renamed
so that they don't have any effect in user code including our headers.

Also use larger type for result of filesystem::file_size to avoid
truncation of large values on 32-bit systems (PR 91947).

PR libstdc++/81091
PR libstdc++/91947
* configure.ac: Use AC_SYS_LARGEFILE to enable 64-bit file APIs.
* config.h.in: Regenerate:
* configure: Regenerate:
* include/Makefile.am (${host_builddir}/largefile-config.h): New
target to generate config header for filesystem library.
(${host_builddir}/c++config.h): Rename macros for large file support.
* include/Makefile.in: Regenerate.
* src/c++17/fs_dir.cc: Include new config header.
* src/c++17/fs_ops.cc: Likewise.
(filesystem::file_size): Use uintmax_t for size.
* src/filesystem/dir.cc: Include new config header.
* src/filesystem/ops.cc: Likewise.
(experimental::filesystem::file_size): Use uintmax_t for size.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/src/c++17/fs_dir.cc
trunk/libstdc++-v3/src/c++17/fs_ops.cc
trunk/libstdc++-v3/src/filesystem/dir.cc
trunk/libstdc++-v3/src/filesystem/ops.cc

[Bug rtl-optimization/91981] Speed degradation because of inlining a register clobbering function

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Attempting shrink-wrapping optimization.
Block 2 needs the prologue.

(That's the entry block, already).  And in fact it does need the prologue,
it has

movq%rdi, %rbx  # 2 [c=4 l=3]  *movdi_internal/3

This was already decided by IRA:

(insn 2 87 3 2 (set (reg/v/f:DI 105 [ v ])
(reg:DI 115)) "91981.c":46:30 66 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 115)
(nil)))

and IRA picked

   16:r82  l0 1   17:r83  l0 08:r88  l0 16:r89  l0 6
   12:r92  l0404:r93  l0415:r94  l0407:r95  l0 5
   27:r97  l0 22:r100 l0 6   10:r103 l0 09:r104 l0 0
0:r105 l0 3   18:r106 l0 0   15:r107 l0 1   14:r109 l0 1
   13:r111 l0 03:r113 l0401:r114 l0 6   19:r115 l0 5
   11:r116 l0 0

(105 gets bx, 115 gets di).

Ideally IRA will choose register better, not use non-volatile registers
early in the function.  But shrink-wrapping could try to correct for that;
that has been on my to-do for a long time now, but it is hard to come up
with good heuristics.

There are three mechanisms that can be used:

1) Rename registers.  Sometimes you can shuffle the registers a bit such
that the one you care about gets a volatile register.
2) More feasible, you can create register copies to move the stuff around.
Sometimes late passes can get rid of those copies, even.
3) You can copy the code using those non-volatile registers to all successor
blocks.  Or just the code that sets the register.  And you have to be careful
that the inputs to the code you copy are still live at the new position(s),
etc.

Often you cannot get rid of *all* non-volatile registers, even in the entry
block.  Deciding which to get rid of, where, and how, is quite a big problem.

But maybe there is some simple heuristic that works well that I just fail
to see :-)

[Bug preprocessor/91991] ICE in linemap_macro_map_lookup when LTO-building SQLite after r275402

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-04
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/91981] Speed degradation because of inlining a register clobbering function

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Okay, I can reproduce it now.

[Bug rtl-optimization/91981] Speed degradation because of inlining a register clobbering function

[antoshkka at gmail dot com]

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

--- Comment #4 from Antony Polukhin  ---
It was broken in GCC-9, GCC-8.3 and below do not have this issue.

[Bug preprocessor/91991] New: ICE in linemap_macro_map_lookup when LTO-building SQLite after r275402

[jamborm at gcc dot gnu.org]

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

Bug ID: 91991
   Summary: ICE in linemap_macro_map_lookup when LTO-building
SQLite after r275402
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, nathan at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

since r275402 (git mirror commit 8bc9c0bbee9), attempts to build
SQLite with LTO result in an ICE:

during IPA pass: materialize-all-clones
In function 'fts5ExprPhraseIsMatch.isra.0':
lto1: internal compiler error: in linemap_macro_map_lookup, at
libcpp/line-map.c:1007
during IPA pass: materialize-all-clones
In function 'rtreeCheckGetNode':   
lto1: internal compiler error: in linemap_macro_map_lookup, at
libcpp/line-map.c:1007
0x15d17b3 linemap_macro_map_lookup 
/home/mjambor/gcc/mine/src/libcpp/line-map.c:1007
0x15d17b3 linemap_lookup(line_maps*, unsigned int)
/home/mjambor/gcc/mine/src/libcpp/line-map.c:941
0x15d23be get_pure_location(line_maps*, unsigned int)
/home/mjambor/gcc/mine/src/libcpp/line-map.c:331
0x15d17b3 linemap_macro_map_lookup 
/home/mjambor/gcc/mine/src/libcpp/line-map.c:1007
0x15d17b3 linemap_lookup(line_maps*, unsigned int)
/home/mjambor/gcc/mine/src/libcpp/line-map.c:941
0x15d23be get_pure_location(line_maps*, unsigned int)
/home/mjambor/gcc/mine/src/libcpp/line-map.c:331
0xe41836 get_pure_location 
/home/mjambor/gcc/mine/src/gcc/input.h:147
0xe41836 set_block(unsigned int, tree_node*)
/home/mjambor/gcc/mine/src/gcc/tree.c:14938
0x1457efc gimple_set_block 
/home/mjambor/gcc/mine/src/gcc/gimple.h:1796
0x1457efc input_gimple_stmt
/home/mjambor/gcc/mine/src/gcc/gimple-streamer-in.c:114
0x1457efc input_bb(lto_input_block*, LTO_tags, data_in*, function*, int)
/home/mjambor/gcc/mine/src/gcc/gimple-streamer-in.c:283
0xe41836 get_pure_location 
/home/mjambor/gcc/mine/src/gcc/input.h:147
0xe41836 set_block(unsigned int, tree_node*)
/home/mjambor/gcc/mine/src/gcc/tree.c:14938
0x1457efc gimple_set_block 
/home/mjambor/gcc/mine/src/gcc/gimple.h:1796
0x1457efc input_gimple_stmt
/home/mjambor/gcc/mine/src/gcc/gimple-streamer-in.c:114
0x1457efc input_bb(lto_input_block*, LTO_tags, data_in*, function*, int)
/home/mjambor/gcc/mine/src/gcc/gimple-streamer-in.c:283
0x9c6c5e input_function
/home/mjambor/gcc/mine/src/gcc/lto-streamer-in.c:1094
0x9c6c5e lto_read_body_or_constructor  
/home/mjambor/gcc/mine/src/gcc/lto-streamer-in.c:1305
0x9c6c5e input_function
/home/mjambor/gcc/mine/src/gcc/lto-streamer-in.c:1094
0x9c6c5e lto_read_body_or_constructor  
/home/mjambor/gcc/mine/src/gcc/lto-streamer-in.c:1305
0x6c2a44 cgraph_node::get_untransformed_body()
/home/mjambor/gcc/mine/src/gcc/cgraph.c:3616
0x6d769c symbol_table::materialize_all_clones()
/home/mjambor/gcc/mine/src/gcc/cgraphclones.c:1179
0x6c2a44 cgraph_node::get_untransformed_body()
/home/mjambor/gcc/mine/src/gcc/cgraph.c:3616
0x6d769c symbol_table::materialize_all_clones()
/home/mjambor/gcc/mine/src/gcc/cgraphclones.c:1179
0x9431bf execute   
/home/mjambor/gcc/mine/src/gcc/ipa.c:1396
0x9431bf execute   
/home/mjambor/gcc/mine/src/gcc/ipa.c:1396
Please submit a full bug report,   
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Please submit a full bug report,   
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


In order to reproduce, download sqlite from
https://sqlite.org/download.html (I used
sqlite-snapshot-201909271633.tar.gz), build trunk, set PATH to use the
built trunk compiler, configure with

./configure CFLAGS="-O3 -flto=64" CXXFLAGS="-O3 -flto=64"

and run make.

[Bug debug/91968] DW_AT_low_pc missing for DW_TAG_label with LTO

[keiths at redhat dot com]

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

--- Comment #5 from Keith Seitz  ---
(In reply to Richard Biener from comment #3)
> Fixed on trunk, I'm considering backporting after a while.

Confirmed. Thank you!

[Bug rtl-optimization/91981] Speed degradation because of inlining a register clobbering function

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
So this works just fine with a compiler from a year ago.

[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information

[kamleshbhalui at gmail dot com]

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

Kamlesh Kumar  changed:

   What|Removed |Added

 CC||kamleshbhalui at gmail dot com

--- Comment #4 from Kamlesh Kumar  ---
patch posted https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00309.html

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> Ick.  Have to sort through the fallout below:
> 
> FAIL: g++.dg/tree-ssa/ivopts-3.C  -std=gnu++14  scan-tree-dump ivopts
> "Selected IV set for loop [0-9]* at [^ ]*:64, 3 avg niters, 1 IVs"

unrolling choice is good, IVOPTs one as well (two less IVs for the
originally inner 2-level nest).

> FAIL: gcc.c-torture/execute/loop-3.c   -O1  execution test
> FAIL: gcc.c-torture/execute/loop-3.c   -Os  execution test

undefined testcase

> FAIL: gcc.dg/tree-ssa/cunroll-2.c scan-tree-dump cunroll "loop with 1
> iterations completely unrolled"

happens earlir

> FAIL: gcc.dg/vect/no-vfa-vect-101.c scan-tree-dump vect "can't determine
> dependence"

loop goes away

> FAIL: gcc.dg/vect/no-vfa-vect-102.c scan-tree-dump vect "possible dependence
> between data-refs"

Likewise.

> FAIL: gcc.dg/vect/pr79920.c -flto -ffat-lto-objects  scan-tree-dump-times
> vect "vectorized 2 loops" 1
> FAIL: gcc.dg/vect/pr79920.c scan-tree-dump-times vect "vectorized 2 loops" 1
> FAIL: gcc.dg/vect/pr83202-1.c -flto -ffat-lto-objects  scan-tree-dump vect
> "Loop contains only SLP stmts"
> FAIL: gcc.dg/vect/pr83202-1.c -flto -ffat-lto-objects  scan-tree-dump vect
> "ectorized 1 loops"
> FAIL: gcc.dg/vect/pr83202-1.c scan-tree-dump vect "Loop contains only SLP
> stmts"
> FAIL: gcc.dg/vect/pr83202-1.c scan-tree-dump vect "ectorized 1 loops"
> FAIL: gcc.dg/vect/vect-105.c -flto -ffat-lto-objects  scan-tree-dump-times
> vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/vect-105.c scan-tree-dump-times vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/vect-93.c -flto -ffat-lto-objects  scan-tree-dump-times
> vect "vectorized 2 loops" 2
> FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times vect "vectorized 2 loops" 2
> FAIL: gcc.dg/vect/vect-double-reduc-6.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-double-reduc-6.c scan-tree-dump-times vect "OUTER
> LOOP VECTORIZED" 1
> FAIL: gcc.dg/vect/vect-profile-1.c -flto -ffat-lto-objects  scan-tree-dump
> vect "goto ; [0+.0*%]"
> FAIL: gcc.dg/vect/vect-profile-1.c scan-tree-dump vect "goto ;
> [0+.0*%]"

all unrollings getting in the way, easy to fix

> FAIL: gfortran.dg/vect/vect-8.f90   -O   scan-tree-dump-times vect
> "vectorized 2
> 2 loops" 1

Re-testing with testsuite adjustments.

[Bug rtl-optimization/91981] Speed degradation because of inlining a register clobbering function

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
I didn't have an x86 C++ compiler handy, so I tried on powerpc.  This
isn't a big problem there, since we do separate shrink-wrapping by
default on powerpc; disabling that makes this pretty bad here, too.

Shrink-wrapping does not change the generated code, it just inserts
the prologue/epilogue at some better place(s).

Have a look at what the RTL was at shrink-wrap time?  It looks like
something else change things later.

[Bug debug/91968] DW_AT_low_pc missing for DW_TAG_label with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Fri Oct  4 11:37:16 2019
New Revision: 276571

URL: https://gcc.gnu.org/viewcvs?rev=276571=gcc=rev
Log:
2019-10-04  Richard Biener  

PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree.c

[Bug debug/91968] DW_AT_low_pc missing for DW_TAG_label with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
  Known to fail||9.2.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk, I'm considering backporting after a while.

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Ick.  Have to sort through the fallout below:

FAIL: g++.dg/tree-ssa/ivopts-3.C  -std=gnu++14  scan-tree-dump ivopts "Selected
IV set for loop [0-9]* at [^ ]*:64, 3 avg niters, 1 IVs"
FAIL: gcc.c-torture/execute/loop-3.c   -O1  execution test
FAIL: gcc.c-torture/execute/loop-3.c   -Os  execution test
FAIL: gcc.dg/tree-ssa/cunroll-2.c scan-tree-dump cunroll "loop with 1
iterations completely unrolled"
FAIL: gcc.dg/vect/no-vfa-vect-101.c scan-tree-dump vect "can't determine
dependence"
FAIL: gcc.dg/vect/no-vfa-vect-102.c scan-tree-dump vect "possible dependence
between data-refs"
FAIL: gcc.dg/vect/pr79920.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 2 loops" 1
FAIL: gcc.dg/vect/pr79920.c scan-tree-dump-times vect "vectorized 2 loops" 1
FAIL: gcc.dg/vect/pr83202-1.c -flto -ffat-lto-objects  scan-tree-dump vect
"Loop contains only SLP stmts"
FAIL: gcc.dg/vect/pr83202-1.c -flto -ffat-lto-objects  scan-tree-dump vect
"ectorized 1 loops"
FAIL: gcc.dg/vect/pr83202-1.c scan-tree-dump vect "Loop contains only SLP
stmts"
FAIL: gcc.dg/vect/pr83202-1.c scan-tree-dump vect "ectorized 1 loops"
FAIL: gcc.dg/vect/vect-105.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-105.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-93.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 2 loops" 2
FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times vect "vectorized 2 loops" 2
FAIL: gcc.dg/vect/vect-double-reduc-6.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
FAIL: gcc.dg/vect/vect-double-reduc-6.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
FAIL: gcc.dg/vect/vect-profile-1.c -flto -ffat-lto-objects  scan-tree-dump vect
"goto ; [0+.0*%]"
FAIL: gcc.dg/vect/vect-profile-1.c scan-tree-dump vect "goto ;
[0+.0*%]"
FAIL: gfortran.dg/vect/vect-8.f90   -O   scan-tree-dump-times vect "vectorized
2
2 loops" 1

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

--- Comment #10 from Aurelien Jarno  ---
Thanks!

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[dragan.mladjeno...@rt-rk.com]

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

--- Comment #9 from Dragan Mladjenovic  ---
Sorry for the delay. I somehow managed to get my git svn rebase to take hours.
Both patches have been backported.

[Bug target/91769] [9/10 regression] wrong code with -O2 on MIPS

[draganm at gcc dot gnu.org]

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

--- Comment #8 from draganm at gcc dot gnu.org ---
Author: draganm
Date: Fri Oct  4 11:10:01 2019
New Revision: 276570

URL: https://gcc.gnu.org/viewcvs?rev=276570=gcc=rev
Log:
Backport fix for PR target/91769

gcc/ChangeLog:

2019-10-04  Dragan Mladjenovic 

Backport from mainline
2019-10-03  Dragan Mladjenovic  

PR target/91769
* config/mips/mips.c (mips_split_move): Use
reg_overlap_mentioned_p
instead of REGNO equality check on addr.reg.

gcc/testsuite/ChangeLog:

2019-10-04  Dragan Mladjenovic 

Backport from mainline
2019-10-03  Dragan Mladjenovic  

PR target/91769
* gcc.target/mips/pr91769.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/mips/pr91769.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/mips/mips.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91990] New: Too slow compilation of recursively-nested template class with two instances of its template parent

[b7.10110111 at gmail dot com]

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

Bug ID: 91990
   Summary: Too slow compilation of recursively-nested template
class with two instances of its template parent
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Consider the following code:
```
template class A
{
typedef A B;
B x, y;
};
template<> class A<0> { char m; };
int main()
{
A a;
}
```
Depending on the value of `LEVEL`, g++ compilation takes exponential time. But
if you replace `x, y` with `x[2]`, compilation will be in constant (negligibly
small) time. I've tested this on g++ 6.5.0, 8.3.0 and 9.1.0, and in all these
versions the problem of slow compilation reproduces.

For comparison, clang++ 6.0 compiles both versions (with `x, y` and `x[2]`) in
negligibly small time regardless of `LEVEL` (tested up to `LEVEL=906`, on 907
it crashes).

[Bug other/91989] New: libssp/spp.c: __[stack_]chk_fail() may run arbitrary code if __builtin_trap() returns

[franke at computer dot org]

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

Bug ID: 91989
   Summary: libssp/spp.c: __[stack_]chk_fail() may run arbitrary
code if __builtin_trap() returns
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: franke at computer dot org
  Target Milestone: ---

Issue found in MinGW-w64 GCC 7.4.0 from current Cygwin package, but still
applies to current SVN trunk (r276567):

The abort code used by __[stack_]chk_fail() assumes that something may prevent
__builtin_trap() (and segfault) from working:

libssp/ssp.c:
static void
fail (..)
{
  ...
  /* Try very hard to exit.  Note that signals may be blocked preventing
 the first two options from working.  The use of volatile is here to
 prevent optimizers from "knowing" that __builtin_trap is called first,
 and that it doesn't return, and so "obviously" the rest of the code
 is dead.  */
  {
volatile int state;
for (state = 0; ; state++)
  switch (state)
{
case 0:
  __builtin_trap ();
  break;
case 1:
  *(volatile int *)-1L = 0;
  break;
case 2:
  _exit (127);
  break;
}
  }
}

The volatile state variable only prevents that the loop is optimized away, but
does not prevent that the compiler assumes an __attribute__((noreturn)) for
__builtin_trap():

gcc/builtins.c:
void
expand_builtin_trap (void)
{
  ...
  emit_barrier ();
}

Depending on how the optimizer moves code around, this may result in arbitrary
code following __builtin_trap(). In libssp.a from Mingw-w64 GCC 7.0.3, the
generated code is equivalent to:

volatile int state;
for (state = 0; ; state++)
  switch (state)
{
case 0:
  __builtin_trap ();
  // fall through ...
case 2:
  _exit (127);
  break;
case 1:
  *(volatile int *)-1L = 0;
  break;
}

In this case, we were lucky. But if gcc would decide to move 'case 0:' code to
the end of the function, arbitrary code from start of next function would be
executed.

Conclusion: If there are runtime settings that let __buildin_trap() return, the
compiler should not assume an __attribute__((noreturn)) for this builtin. If
there are no such settings, the volatile loop in ssp.c is not needed.

[Bug target/91702] [9/10 Regression] ICE with mips16

[draganm at gcc dot gnu.org]

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

--- Comment #3 from draganm at gcc dot gnu.org ---
Author: draganm
Date: Fri Oct  4 10:57:48 2019
New Revision: 276569

URL: https://gcc.gnu.org/viewcvs?rev=276569=gcc=rev
Log:
Backprot fix for uninitialised use in mips_split_move

Fixes PR target/91474 and PR target/91702.

2019-10-04  Dragan Mladjenovic  

Backport from mainline
2019-07-07  Richard Sandiford  

gcc/
* config/mips/mips.c (mips_split_move): Zero-initialize addr
and check whether addr.reg is nonnull before using it.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/mips/mips.c

[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[draganm at gcc dot gnu.org]

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

--- Comment #10 from draganm at gcc dot gnu.org ---
Author: draganm
Date: Fri Oct  4 10:57:48 2019
New Revision: 276569

URL: https://gcc.gnu.org/viewcvs?rev=276569=gcc=rev
Log:
Backprot fix for uninitialised use in mips_split_move

Fixes PR target/91474 and PR target/91702.

2019-10-04  Dragan Mladjenovic  

Backport from mainline
2019-07-07  Richard Sandiford  

gcc/
* config/mips/mips.c (mips_split_move): Zero-initialize addr
and check whether addr.reg is nonnull before using it.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/mips/mips.c

[Bug lto/70929] [7/8/9/10 regression] Cross-module inlining for functions having argument passed by reference is no longer working.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||gcc-bugzilla at tobias dot 
goedder
   ||z.info

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

[Bug ipa/91988] Inlining fails with LTO enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Duplicate.

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

[Bug ipa/91988] Inlining fails with LTO enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The failure is triggered by compile-time(!)

Breakpoint 6, symbol_table::create_edge (this=0x76810100, 
caller=, 
callee=, call_stmt=0x77fefea0, 
count=..., indir_unknown_callee=false)
at /space/rguenther/src/svn/gcc-9-branch/gcc/cgraph.c:884
884   edge->inline_failed = CIF_MISMATCHED_ARGUMENTS;

and also

Breakpoint 7, early_inliner (fun=0x7696b210)
at /space/rguenther/src/svn/gcc-9-branch/gcc/ipa-inline.c:2841
2841  edge->inline_failed = CIF_MISMATCHED_ARGUMENTS;

we ultimatively call

types_compatible_p (type1=, 
type2=)

from

static bool
gimple_check_call_args (gimple *stmt, tree fndecl, bool args_count_match)
{
...
  if (TREE_VALUE (p) == error_mark_node
  || arg == error_mark_node
  || TREE_CODE (TREE_VALUE (p)) == VOID_TYPE
  || (!types_compatible_p (TREE_VALUE (p), TREE_TYPE (arg))
  && !fold_convertible_p (TREE_VALUE (p), arg)))
return false;

we're looking at TYPE_ARG_TYPES here because we don't have a PARM_DECL
and as we know TYPE_ARG_TYPES do _not_ reflect by-reference semantics.
But we could take TREE_ADDRESSABLE as a hint.

Index: gcc/cgraph.c
===
--- gcc/cgraph.c(revision 276396)
+++ gcc/cgraph.c(working copy)
@@ -3728,7 +3728,10 @@ gimple_check_call_args (gimple *stmt, tr
  || arg == error_mark_node
  || TREE_CODE (TREE_VALUE (p)) == VOID_TYPE
  || (!types_compatible_p (TREE_VALUE (p), TREE_TYPE (arg))
- && !fold_convertible_p (TREE_VALUE (p), arg)))
+ && !fold_convertible_p (TREE_VALUE (p), arg)
+ /* TREE_ADDRESSABLE types are passed by reference.  */
+ && !(POINTER_TYPE_P (TREE_TYPE (arg))
+  && TREE_ADDRESSABLE (TREE_VALUE (p)
 return false;
}
 }

fixes that (comparing the pointed-do type is probably too strict here).

[Bug c/91952] [rfe] __attribute__((__default_value__()))

[allison.karlitskaya at redhat dot com]

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

--- Comment #5 from Allison Karlitskaya  
---
One could imagine (as a first step) that __default_value__() would be
implemented by way of a simple code transformation whenever it is encountered. 
An additional block could be added and the variable declaration and its initial
value would be lifted out of its current location to the start of the new
block.

Given the example:

(In reply to Jakub Jelinek from comment #3)
> switch (n)
> {
>   int x __attribute__((__default_value__((5)));
>   case 10:
> foo (x);
>   case 20:
> foo (x);
> break;
> }

the transformed code would look something like:

{
  int x = 5;

  switch (n)
  {
case 10:
  foo (x);
case 20:
  foo (x);
  break;
  }
}


I'm no compiler author, of course, and this might be a ridiculous way to
approach the implementation (and probably also has some edge cases where it
doesn't work properly), but it's another way to describe what I'm talking about
and argue in favour of its feasibility (regardless of concerns such as whether
the variable in question lands on the stack or in a register, etc.)

[Bug c/91952] [rfe] __attribute__((__default_value__()))

[allison.karlitskaya at redhat dot com]

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

--- Comment #4 from Allison Karlitskaya  
---
(In reply to Jakub Jelinek from comment #3)
> First of all, not all automatic vars live on stack, some live in registers.

Sure.  The register could also be initialised to the same value, of course.

> And, what will happen say for:
> switch (n)
> {
>   int x __attribute__((__default_value__((5)));
>   case 10:
> foo (x);
>   case 20:
> foo (x);
> break;
> }

This is pretty much exactly the case that I'm talking about and the answer is
that foo() would *always* be called with 5.  The initialisation of 5 with this
attribute isn't done in the normal sense of an assignment that occurs when the
line in question is executed (note: there is no '=' anywhere in this program). 
The value of 5 is written into the local variable (register or stack space) as
soon as it is allocated, regardless of if execution passes through the line
where the declaration is.

[Bug ipa/91988] Inlining fails with LTO enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> I see IPA-CP being applied and that function not inlined.
> 
> Deciding on inlining of small functions.  Starting with size 9.
> Enqueueing calls in fun.constprop/9.
> Enqueueing calls in main/3.
> missed:   not inlinable: main/3 -> fun.constprop/9, mismatched arguments
> Unit growth for small function inlining: 9->9 (0%)
> 
> looks like the inliner predicate needs to consider IPA-CP transform
> being applied somehow?

hmm, w/o LTO and early inlining disabled a single-TU testcase is fine:

Deciding on inlining of small functions.  Starting with size 12.
Enqueueing calls in fun.constprop/6.
Enqueueing calls in int main()/4.
   Estimating body: fun.constprop/6
   Known to be false: not inlined
   size:0 time:0.00 nonspec time:2.00
   Estimating body: fun.constprop/6
   Known to be false: not inlined
   size:0 time:0.00 nonspec time:2.00
  enqueuing call int main()/4 -> fun.constprop/6, badness -inf
Enqueueing calls in int fun(A)/3.
   Estimating body: fun.constprop/6
   Known to be false: not inlined
   size:0 time:0.00 nonspec time:2.00
...
t3.C:6:13: optimized:  Inlined fun.constprop/6 into int main()/4 which now has
time 2.00 and size 3, net change of -6.

[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
So, if clang is right here, we'd need to force arguments not just with
is_gimple_reg_type, but also with all other types that are not
TREE_ADDRESSABLE, into temporaries (perhaps with a first check we really need
to do that, as in whether the other argument(s) has/have side-effects.

[Bug ipa/91988] Inlining fails with LTO enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-04
 CC||jamborm at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|lto |ipa
 Ever confirmed|0   |1
  Known to fail||9.2.0

--- Comment #2 from Richard Biener  ---
I see IPA-CP being applied and that function not inlined.

Deciding on inlining of small functions.  Starting with size 9.
Enqueueing calls in fun.constprop/9.
Enqueueing calls in main/3.
missed:   not inlinable: main/3 -> fun.constprop/9, mismatched arguments
Unit growth for small function inlining: 9->9 (0%)

looks like the inliner predicate needs to consider IPA-CP transform
being applied somehow?

[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #4)
> Probably, but aggregate copy of TREE_ADDRESSABLE aggregates might be a
> problem.
> For the arguments, I'm not planning to do anything myself, because I don't
> understand it well, just wanted to raise possible issue.

For this I meant something like:
struct S { S (); ~S (); S (const S &); int s; S operator<< (const S &); };

void
foo ()
{
  S a, b, c;
  c = a << (a.s = 5, b);
}
which according to godbolt all of gcc, clang and icpc handle the same in
-std=c++17 mode, the first argument (this) to the method points to a that has
been modified, then
struct S { S (); ~S (); S (const S &); int s; };
S operator<< (const S &, const S &);

void
foo ()
{
  S a, b, c;
  c = a << (a.s = 5, b);
}

(likewise) and finally
struct S { int s; };
S operator<< (S, S);

void
foo ()
{
  S a, b, c;
  a.s = 1;
  b.s = 2;
  c.s = 3;
  c = a << (a.s = 5, b);
}

This one according to godbolt is handled differently, gcc and icpc will call
the operator with S{5}, S{2}, while clang with S{1}, S{2}.

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  ---
Any news about this?

[Bug lto/91988] Inlining fails with LTO enabled

[gcc-bugzilla at tobias dot goedderz.info]

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

--- Comment #1 from Tobias Gödderz  
---
Happens with GCC 9.1.0 as well.

[Bug c++/91987] -fstrict-eval-order issues

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 4 Oct 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987
> 
> --- Comment #4 from Jakub Jelinek  ---
> (In reply to rguent...@suse.de from comment #3)
> > Ick.  I'd say we should unconditionally guard the transform
> > with the appropriate TREE_SIDE_EFFECTS check?
> 
> See above, wouldn't that mean throwing the optimization away completely,
> because COMPOUND_EXPRs with no side-effects in the rhs1 should be just
> optimized into rhs2?
> Do you mean unconditionally for all binary/comparison ops, or just the
> shifts/rotates?
> For languages where it is UB if the side-effects modify the other operands, I
> don't see
> anything wrong with continuing with the optimization.

Well, AFAICS this "optimization" is purely for frontend folding
since in the middle-end we have expressions not "obfuscated" with
COMPOUND_EXPRs.  So I wouldn't mind dropping it completely either...

> The other C++17 rules are summarized in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415#c5
> (though that PR is also unfinished).
> 
> > > One thing I'm worried about are the special cases where we enforce some
> > > argument order, evaluate one argument before the other or vice versa.
> > > For is_gimple_reg_type args it can be just a matter of forcing it into an
> > > SSA_NAME or a new VAR_DECL, but if a function argument is a structure,
> > > struct S { int a, b; } c = { 1, 2 };
> > > fun (c, (c.b = 3, 5);
> > > and fun is one of the magic one that enforce operand ordering and the 
> > > first
> > > argument needs to be sequenced before the second, what can we do?
> > 
> > You need to emit an aggregate copy, don't you?  Consider
> 
> Probably, but aggregate copy of TREE_ADDRESSABLE aggregates might be a 
> problem.
> For the arguments, I'm not planning to do anything myself, because I don't
> understand it well, just wanted to raise possible issue.

Likewise.  I don't even _want_ to understand :P

[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #3)
> Ick.  I'd say we should unconditionally guard the transform
> with the appropriate TREE_SIDE_EFFECTS check?

See above, wouldn't that mean throwing the optimization away completely,
because COMPOUND_EXPRs with no side-effects in the rhs1 should be just
optimized into rhs2?
Do you mean unconditionally for all binary/comparison ops, or just the
shifts/rotates?
For languages where it is UB if the side-effects modify the other operands, I
don't see
anything wrong with continuing with the optimization.

The other C++17 rules are summarized in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415#c5
(though that PR is also unfinished).

> > One thing I'm worried about are the special cases where we enforce some
> > argument order, evaluate one argument before the other or vice versa.
> > For is_gimple_reg_type args it can be just a matter of forcing it into an
> > SSA_NAME or a new VAR_DECL, but if a function argument is a structure,
> > struct S { int a, b; } c = { 1, 2 };
> > fun (c, (c.b = 3, 5);
> > and fun is one of the magic one that enforce operand ordering and the first
> > argument needs to be sequenced before the second, what can we do?
> 
> You need to emit an aggregate copy, don't you?  Consider

Probably, but aggregate copy of TREE_ADDRESSABLE aggregates might be a problem.
For the arguments, I'm not planning to do anything myself, because I don't
understand it well, just wanted to raise possible issue.

[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Oct  4 09:18:26 2019
New Revision: 276566

URL: https://gcc.gnu.org/viewcvs?rev=276566=gcc=rev
Log:
2019-10-04  Richard Biener  

PR tree-optimization/91982
* tree-vect-loop.c (vectorizable_live_operation): Also guard
against EXTRACT_LAST_REDUCTION.
* tree-vect-stmts.c (vect_transform_stmt): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c

[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Should be fixed.

[Bug c++/91987] -fstrict-eval-order issues

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 4 Oct 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91987
> 
> --- Comment #2 from Jakub Jelinek  ---
> So for the shifts we'd need additionally:
> --- gcc/fold-const.c.jj 2019-09-02 15:29:34.548515139 +0200
> +++ gcc/fold-const.c2019-10-04 10:44:23.319883187 +0200
> @@ -9447,16 +9447,23 @@ fold_binary_loc (location_t loc, enum tr
>if (TREE_CODE (arg0) == COMPOUND_EXPR)
> {
>   tem = fold_build2_loc (loc, code, type,
> -fold_convert_loc (loc, TREE_TYPE (op0),
> -  TREE_OPERAND (arg0, 1)), op1);
> +fold_convert_loc (loc, TREE_TYPE (op0),
> +  TREE_OPERAND (arg0, 1)),
> +  op1);
>   return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
>  tem);
> }
> -  if (TREE_CODE (arg1) == COMPOUND_EXPR)
> +  if (TREE_CODE (arg1) == COMPOUND_EXPR
> + && (flag_strong_eval_order != 2
> + /* C++17 disallows this canonicalization for shifts.  */
> + || (code != LSHIFT_EXPR
> + && code != RSHIFT_EXPR
> + && code != LROTATE_EXPR
> + && code != RROTATE_EXPR)))
> {
>   tem = fold_build2_loc (loc, code, type, op0,
> -fold_convert_loc (loc, TREE_TYPE (op1),
> -  TREE_OPERAND (arg1, 1)));
> +fold_convert_loc (loc, TREE_TYPE (op1),
> +  TREE_OPERAND (arg1, 1)));
>   return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0),
>  tem);
> }

Ick.  I'd say we should unconditionally guard the transform
with the appropriate TREE_SIDE_EFFECTS check?

> One thing I'm worried about are the special cases where we enforce some
> argument order, evaluate one argument before the other or vice versa.
> For is_gimple_reg_type args it can be just a matter of forcing it into an
> SSA_NAME or a new VAR_DECL, but if a function argument is a structure,
> struct S { int a, b; } c = { 1, 2 };
> fun (c, (c.b = 3, 5);
> and fun is one of the magic one that enforce operand ordering and the first
> argument needs to be sequenced before the second, what can we do?

You need to emit an aggregate copy, don't you?  Consider

int i;

void fun (int i, int j)
{
  assert (i == 0 && j == 1);
}

and

i = 0;
fun (i, (i = 1, 5));

so you cannot gimplify to the post-call sequence.  For the
aggregate case it might be

fun (S , S )

so handling of

fun (c, c = {})

needs a temporary anyways?

[Bug c/91952] [rfe] __attribute__((__default_value__()))

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
First of all, not all automatic vars live on stack, some live in registers.
And, what will happen say for:
switch (n)
{
  int x __attribute__((__default_value__((5)));
  case 10:
foo (x);
  case 20:
foo (x);
break;
}
where the initialization, even if done early, is jumped over?

[Bug target/91967] gtest from google generates incorrect assembly code on x86 solaris

[bobw at cristie dot com]

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

--- Comment #3 from bob wilkinson  ---
You are correct it is inline assembly ...

4768 #elif (!defined(__native_client__)) &&\
4769 ((defined(__clang__) || defined(__GNUC__)) && \
4770  (defined(__x86_64__) || defined(__i386__)))
4771   // with clang/gcc we can achieve the same effect on x86 by invoking
int3
4772   asm("int3");
4773 #else

from gtest_1_9_0/googletest/src/gtest.cc

so I think that this is a google error, rather than gcc.

Please close this bug. It is not an error in gcc.

[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
So for the shifts we'd need additionally:
--- gcc/fold-const.c.jj 2019-09-02 15:29:34.548515139 +0200
+++ gcc/fold-const.c2019-10-04 10:44:23.319883187 +0200
@@ -9447,16 +9447,23 @@ fold_binary_loc (location_t loc, enum tr
   if (TREE_CODE (arg0) == COMPOUND_EXPR)
{
  tem = fold_build2_loc (loc, code, type,
-fold_convert_loc (loc, TREE_TYPE (op0),
-  TREE_OPERAND (arg0, 1)), op1);
+fold_convert_loc (loc, TREE_TYPE (op0),
+  TREE_OPERAND (arg0, 1)),
+  op1);
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
 tem);
}
-  if (TREE_CODE (arg1) == COMPOUND_EXPR)
+  if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && (flag_strong_eval_order != 2
+ /* C++17 disallows this canonicalization for shifts.  */
+ || (code != LSHIFT_EXPR
+ && code != RSHIFT_EXPR
+ && code != LROTATE_EXPR
+ && code != RROTATE_EXPR)))
{
  tem = fold_build2_loc (loc, code, type, op0,
-fold_convert_loc (loc, TREE_TYPE (op1),
-  TREE_OPERAND (arg1, 1)));
+fold_convert_loc (loc, TREE_TYPE (op1),
+  TREE_OPERAND (arg1, 1)));
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0),
 tem);
}

One thing I'm worried about are the special cases where we enforce some
argument order, evaluate one argument before the other or vice versa.
For is_gimple_reg_type args it can be just a matter of forcing it into an
SSA_NAME or a new VAR_DECL, but if a function argument is a structure,
struct S { int a, b; } c = { 1, 2 };
fun (c, (c.b = 3, 5);
and fun is one of the magic one that enforce operand ordering and the first
argument needs to be sequenced before the second, what can we do?

[Bug c++/91987] -fstrict-eval-order issues

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
To sum up IRC discussion with richi, he doesn't want this to be in the
gimplifier, as it is one FE specific, which means cp-gimplify.c is where this
needs to be done.
Furthermore, if we there have a predicate which for flag_strong_eval_order == 2
will fail for user decls (note, I still don't know how to safely recognize the
"safe" gimple temporaries), we could force stuff into temporaries too often,
e.g. for this case, we only need to do it if the other operand that is to be
sequenced after has side-effects.
So, I thought something along the lines of:
--- gcc/cp/cp-gimplify.c.jj 2019-10-04 08:53:01.737740712 +0200
+++ gcc/cp/cp-gimplify.c2019-10-04 10:15:07.629709617 +0200
@@ -884,6 +884,29 @@ cp_gimplify_expr (tree *expr_p, gimple_s
}
   break;

+case LSHIFT_EXPR:
+case RSHIFT_EXPR:
+case LROTATE_EXPR:
+case RROTATE_EXPR:
+  /* If the second operand has side-effects, ensure the first operand
+is evaluated first and is not a decl that the side-effects of the
+second operand could modify.  */
+  if (flag_strong_eval_order == 2
+ && TREE_SIDE_EFFECTS (TREE_OPERAND (*expr_p, 1)))
+   {
+ enum gimplify_status t
+   = gimplify_expr (_OPERAND (*expr_p, 0), pre_p, post_p,
+is_gimple_val, fb_rvalue);
+ if (t == GS_ERROR)
+   break;
+ else if (is_gimple_variable (TREE_OPERAND (*expr_p, 0))
+  && TREE_CODE (TREE_OPERAND (*expr_p, 0)) != SSA_NAME)
+   TREE_OPERAND (*expr_p, 0)
+ = get_initialized_tmp_var (TREE_OPERAND (*expr_p, 0), pre_p,
+NULL);
+   }
+  goto do_default;  
+
 case RETURN_EXPR:
   if (TREE_OPERAND (*expr_p, 0)
  && (TREE_CODE (TREE_OPERAND (*expr_p, 0)) == INIT_EXPR
@@ -897,6 +920,7 @@ cp_gimplify_expr (tree *expr_p, gimple_s
}
   /* Fall through.  */

+do_default:
 default:
   ret = (enum gimplify_status) c_gimplify_expr (expr_p, pre_p, post_p);
   break;

and similarly for the other occurrences of E? is sequenced before E? in the
standard.
Unfortunately, on the above testcase this doesn't work, because it is already
broken earlier, fold_binary_loc (invoked during cp_fold) has:
  if (TREE_CODE_CLASS (code) == tcc_binary
  || TREE_CODE_CLASS (code) == tcc_comparison)
{
  if (TREE_CODE (arg0) == COMPOUND_EXPR)
{
  tem = fold_build2_loc (loc, code, type,
 fold_convert_loc (loc, TREE_TYPE (op0),
   TREE_OPERAND (arg0, 1)), op1);
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
 tem);
}
  if (TREE_CODE (arg1) == COMPOUND_EXPR)
{
  tem = fold_build2_loc (loc, code, type, op0,
 fold_convert_loc (loc, TREE_TYPE (op1),
   TREE_OPERAND (arg1, 1)));
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0),
 tem);
}
where the last if is invalid for the shifts (and rotates?) in
flag_strict_eval_order == 2 (at least if TREE_SIDE_EFFECTS (TREE_OPERAND (arg1,
1)), but for a COMPOUND_EXPR it would likely be optimized into just the last
operand if the first one doesn't have side-effects).

[Bug lto/91988] New: Inlining fails with LTO enabled

[gcc-bugzilla at tobias dot goedderz.info]

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

Bug ID: 91988
   Summary: Inlining fails with LTO enabled
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at tobias dot goedderz.info
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Inlining fails with LTO when there is an argument with a destructor. This seems
unintentional to me, given the following behaviour.

Given the following example files:

==> main.cpp <==
#include "lib.h"

int main() {
  return fun(A{});
}

==> lib.h <==
#ifndef LIB_H
#define LIB_H

class A { public: ~A() {} };

__attribute__((always_inline))
int fun(A);

#endif // LIB_H

==> lib.cpp <==
#include "lib.h"

__attribute__((always_inline))
int fun(A a) { return 0; }


and compiling with

/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c lib.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c main.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -o main-gcc main.o lib.o

fails with
  error: inlining failed in call to always_inline ‘fun(A)’: mismatched
arguments
in the last step.

Removing "__attribute__((always_inline))" and inspecting the deassembled output
confirms that the function isn't inlined.

If the body is moved to the header file (and the "inline" specifier added), the
function is inlined.

If the destructor of "A" is removed, or changed to "~A() = default", the
function is inlined.

If the argument to "fun" is changed to a "const&", the function is inlined.

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
The issue mentioned is fixed there, the code now reads correctly

  if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
  && multiple_of_p (type, arg0, arg1))
return fold_build2_loc (loc, EXACT_DIV_EXPR, type,
fold_convert (type, arg0),
fold_convert (type, arg1));

[Bug debug/91968] DW_AT_low_pc missing for DW_TAG_label with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So the simple reason is we strip them during free-lang-data.  Fix:

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 276396)
+++ gcc/tree.c  (working copy)
@@ -5936,8 +5936,9 @@ find_decls_types_r (tree *tp, int *ws, v
 {
   for (tree *tem = _VARS (t); *tem; )
{
- if (TREE_CODE (*tem) != VAR_DECL
- || !auto_var_in_fn_p (*tem, DECL_CONTEXT (*tem)))
+ if (TREE_CODE (*tem) != LABEL_DECL
+ && (TREE_CODE (*tem) != VAR_DECL
+ || !auto_var_in_fn_p (*tem, DECL_CONTEXT (*tem
{
  gcc_assert (TREE_CODE (*tem) != RESULT_DECL
  && TREE_CODE (*tem) != PARM_DECL);

[Bug tree-optimization/91986] missed loop unrolling optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-04
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So the reason is we cannot compute the number of iterations of the inner loop
and we generally avoid unrolling outer loops.

[Bug c/91952] [rfe] __attribute__((__default_value__()))

[allison.karlitskaya at redhat dot com]

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

--- Comment #2 from Allison Karlitskaya  
---
Consider this example in way of clarification:

void cleanup_func (void **ptr);

void *init (void);

void
function (bool condition)
{
  if (condition)
goto out;

  __attribute__((__cleanup__(cleanup_func)))
__attribute__((__default_value__((NULL
void *x = init ();

out:
  return;
}


On the start of the function, when we allocate stack space for 'x', we would
ensure that a NULL value is written into that space.  If 'condition' is true,
then we exit the function immediately and the cleanup_func is called on the
address of 'x' (and x will contain NULL).

If condition is false then we will proceed to call init() and then write that
value into the variable 'x' and when the function completes we'll clean up that
value.

At no point will it be possible that cleanup_func tries to free an
uninitialised value.


Of course, in many cases optimisation would see that redundant writes are never
performed.  Even in the given case we might imagine the compiler moves the
write of NULL to after the check of 'condition' and only does it in the case
where it won't call init().


I don't see it so much as a 'static automatic' so much as a simple case of
"when you allocate space for this, make sure you fill it in with the given
value immediately".

[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So somehow

last_5 = _4 >= min_v_11(D) ? last_16 : i_17;

has been removed.  I see

last_5 = .FOLD_EXTRACT_LAST (...

in the IL now.  Removing old stmts during transform is really fragile...
(but yes, in-order reductions want to re-use the original cycle).

The following fixes the -1.c testcase (yeah, what a mess ;)).  Unfortunately
a cc1 cross refuses to make-check and I'm not wanting to manually
compile all of sve/*.c

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 276564)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -10897,6 +10897,9 @@ vect_transform_stmt (stmt_vec_info stmt_
   stmt_vec_info orig_stmt_info = vect_orig_stmt (stmt_info);
   if (!slp_node && STMT_VINFO_REDUC_DEF (orig_stmt_info)
   && STMT_VINFO_REDUC_TYPE (orig_stmt_info) != FOLD_LEFT_REDUCTION
+  && (STMT_VINFO_REDUC_TYPE (orig_stmt_info) != COND_REDUCTION
+ || (STMT_VINFO_VEC_REDUCTION_TYPE (orig_stmt_info)
+ != EXTRACT_LAST_REDUCTION))
   && is_a  (STMT_VINFO_REDUC_DEF (orig_stmt_info)->stmt))
 {
   gphi *phi = as_a  (STMT_VINFO_REDUC_DEF (orig_stmt_info)->stmt);
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 276564)
+++ gcc/tree-vect-loop.c(working copy)
@@ -7901,7 +7901,10 @@ vectorizable_live_operation (stmt_vec_in
return true;
   if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def)
{
- if (STMT_VINFO_REDUC_TYPE (stmt_info) == FOLD_LEFT_REDUCTION)
+ if (STMT_VINFO_REDUC_TYPE (stmt_info) == FOLD_LEFT_REDUCTION
+ || (STMT_VINFO_REDUC_TYPE (stmt_info) == COND_REDUCTION
+ && (STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info)
+ == EXTRACT_LAST_REDUCTION)))
return true;
  if (slp_node)
{

[Bug middle-end/91983] g++.dg/tree-ssa/pr61034.C regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/91982] gcc.target/aarch64/sve/clastb_*.c tests failing with segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I will investigate a bit.

[Bug rtl-optimization/91981] Speed degradation because of inlining a register clobbering function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-04
 CC||segher at gcc dot gnu.org
  Component|middle-end  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Sounds like a missed optimization in shrink-wrapping?

[Bug tree-optimization/91975] worse code for small array copy using pointer arithmetic than array indexing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
f1 and g1 are detected as memcpy by loop-distribution.  f0 is unrolled
completely by late unrolling:

  Loop size: 10
  Estimated size after unrolling: 10

while g0 is not:

  Loop size: 8
  Estimated size after unrolling: 20

so the size estimation doesn't quite "work" here.  f0 body before unrolling:

   [local count: 954449108]:
  # i_14 = PHI <0(2), i_10(4)>
  # prephitmp_19 = PHI <0(2), pretmp_18(4)>
  # ivtmp_3 = PHI <8(2), ivtmp_13(4)>
  _1 = (long unsigned int) i_14;
  _2 = _1 * 4;
  _4 =  + _2;
  *_4 = prephitmp_19;
  i_10 = i_14 + 1;
  ivtmp_13 = ivtmp_3 - 1;
  if (ivtmp_13 != 0)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 835156388]:
  _12 = (long unsigned int) i_10;
  _11 = _12 * 4;
  _16 =  + _11;
  pretmp_18 = MEM[(const int *)_16];
  goto ; [100.00%]

g0 body:

   [local count: 954449108]:
  # s_16 = PHI <(2), s_7(4)>
  # d_17 = PHI <(2), d_8(4)>
  # i_18 = PHI <0(2), i_10(4)>
  # prephitmp_4 = PHI <0(2), pretmp_5(4)>
  # ivtmp_3 = PHI <8(2), ivtmp_1(4)>
  s_7 = s_16 + 4;
  d_8 = d_17 + 4;
  *d_17 = prephitmp_4;
  i_10 = i_18 + 1;
  ivtmp_1 = ivtmp_3 - 1;
  if (ivtmp_1 != 0)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 835156388]:
  pretmp_5 = MEM[(const int *)s_16 + 4B];
  goto ; [100.00%]

for g0 we do not think that the s_7 = s_16 + 4 are going to be optimized "away"
but for f0 we think that _4 =  + _2 will.  Those are actually the same.

diff --git a/gcc/tree-ssa-loop-ivcanon.c b/gcc/tree-ssa-loop-ivcanon.c
index 5952cad7bba..d38959c3aa2 100644
--- a/gcc/tree-ssa-loop-ivcanon.c
+++ b/gcc/tree-ssa-loop-ivcanon.c
@@ -195,9 +195,8 @@ constant_after_peeling (tree op, gimple *stmt, class loop
*loop)
   /* Induction variables are constants when defined in loop.  */
   if (loop_containing_stmt (stmt) != loop)
 return false;
-  tree ev = analyze_scalar_evolution (loop, op);
-  if (chrec_contains_undetermined (ev)
-  || chrec_contains_symbols (ev))
+  tree ev = instantiate_parameters (loop, analyze_scalar_evolution (loop,
op));
+  if (chrec_contains_undetermined (ev))
 return false;
   return true;
 }

fixes this but we still end up with

size: 8-6, last_iteration: 7-6
  Loop size: 8
  Estimated size after unrolling: 10
Not unrolling loop 1: size would grow.

and not unrolling because the not unrolled estimate is lower than that for f0
(that costs  + i * 4 as 2 while g0 has IV + 4).

I'm testing the above anyway.