[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
There is also tree-core.h:

/* Call argument flags.  */
/* Nonzero if the argument is not dereferenced recursively, thus only
   directly reachable memory is read or written.  */
#define EAF_DIRECT  (1 << 0)

/* Nonzero if memory reached by the argument is not clobbered.  */
#define EAF_NOCLOBBER   (1 << 1)

/* Nonzero if the argument does not escape.  */
#define EAF_NOESCAPE(1 << 2)

/* Nonzero if the argument is not used by the function.  */
#define EAF_UNUSED  (1 << 3)

/* Call return flags.  */
/* Mask for the argument number that is returned.  Lower two bits of
   the return flags, encodes argument slots zero to three.  */
#define ERF_RETURN_ARG_MASK (3)

/* Nonzero if the return value is equal to the argument number
   flags & ERF_RETURN_ARG_MASK.  */
#define ERF_RETURNS_ARG (1 << 2)

but eventually specifying some terminology and then consistently using that
might help...  Eventually the documentation bits could go to the internals
manual somewhere ('no vops' is also not documented).

[Bug target/92686] Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-27
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Richard Biener  ---
It would be definitely nice to have this.  Maybe add a tunable whether to use
mask registers for SSE/AVX2?  Is there any boost frequency penalty for using
them?  Using mask registers also looks like a way to reduce register pressure
(in case the register pressure is not on the masks side).

[Bug target/92682] [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |10.0
   Target Milestone|--- |10.0

[Bug other/92681] PGO bootstrap with --with-build-config=bootstrap-lto-lean is not training non-C++ frontends

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Is it actually making it worse from non-PGO or do we at least treat missing
profile data as "it wasn't trained"?

[Bug bootstrap/92680] PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
And gmp has a similar issue.

[Bug bootstrap/92680] PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think that's known and was fixed upstream, but the easiest option is to pass
-fno-lto to stage2+ mpfr configure via the host_module config (need to figure
what environment to set exactly and/or invent extra vars honored by bootstrap)

We carry locally in our package

diff --git a/configure b/configure
index 6581c68..a82593c 100755
--- a/configure
+++ b/configure
@@ -16158,7 +16158,7 @@ foo_t foo = {
 };

 EOF
-  mpfr_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >&5 2>&1"
+  mpfr_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c -fno-lto >&5 2>&1"
   if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$mpfr_compile\""; }
>&5
   (eval $mpfr_compile) 2>&5
   ac_status=$?

[Bug c++/92675] sign-conversion C++ unsigned int j = -1;

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-27
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
-1u also works

[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

  Attachment #47357|0   |1
is obsolete||

--- Comment #11 from Kewen Lin  ---
Created attachment 47371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47371&action=edit
47357: Defer vect_setup_realignment for different first_stmt_info

Bootstrapped and tested on powerpc64le-linux-gnu (P8LE) and ppc64-redhat-linux
(P7BE).

[Bug c++/92687] New: decltype of a structured binding to a tuple component is a reference type inside a template function

[vis...@royal-caliber.com]

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

Bug ID: 92687
   Summary: decltype of a structured binding to a tuple component
is a reference type inside a template function
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vis...@royal-caliber.com
  Target Milestone: ---

Created attachment 47370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47370&action=edit
preprocessed file

Hello,

The code below shows an inconsistency in the handling of decltype for
structured bindings within template functions vs. non-template functions - the
static_assert in foo() triggers, but not in bar(). I think the handling in
bar() is correct, as per the notes at
https://en.cppreference.com/w/cpp/language/structured_binding.

This may or may not be related to bug 81176. Details of the compilation command
are listed below the source.

Thank you,
Vishal



#include 
#include 

template 
void foo()
{
  auto [x, y] = std::tuple{0, 2};
  static_assert(!std::is_reference::value);
}

void bar()
{
  auto [x, y] = std::tuple{0, 2};
  static_assert(!std::is_reference::value);
}

int main()
{
  foo<>();
  bar();
}

---

g++-9.2.0 -v -save-temps -pedantic -Wall -Wextra -std=c++17 test.cpp
Using built-in specs.
COLLECT_GCC=g++-9.2.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-9.2.0/work/gcc-9.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 9.2.0 p1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --with-multilib-list=m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0 p1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wpedantic' '-Wall' '-Wextra'
'-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -std=c++17 -Wpedantic -Wall -Wextra
-fpch-preprocess -o test.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wpedantic' '-Wall' '-Wextra'
'-std=c++17' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -Wpedantic
-Wall -Wextra -std=c++17 -version -o test.s
GNU C++17 (Gentoo 9.2.0 p1) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Gentoo 9.2.0 p1) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2f11227cf3606c8ecdab2bd17fc2bf18
test.cpp: In function ‘void foo()’:
test.cpp:9:17: error: static assertion failed
9 |   static_assert(!std::is_reference::value);
  | ^~

[Bug target/92686] Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
My local patch shows there's no big performance impact on SPEC2017.

[Bug ipa/92685] In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers

[erick.oc...@theobroma-systems.com]

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

Erick Ochoa  changed:

   What|Removed |Added

  Attachment #47367|0   |1
is obsolete||

--- Comment #2 from Erick Ochoa  ---
Created attachment 47369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47369&action=edit
Hello World IPA pass (corrected)

[Bug target/92686] New: Inefficient mask operation for 128/256-bit vector VCOND_EXPR under avx512f

[crazylht at gmail dot com]

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

Bug ID: 92686
   Summary: Inefficient mask operation for 128/256-bit vector
VCOND_EXPR under avx512f
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

Cat test.c

void mc_weight( unsigned int *__restrict dst, unsigned int *__restrict src1,
int *__restrict src2)
{
for( int x = 0; x < 16; x++ )
dst[x] = src1[x] > src2[x] ? src1[x] : dst[x];
}

With option -Ofast -march=skylake-avx512

gcc using xmm register as mask and using vpblendvb for condition vector move

vmovdqu32   (%rsi), %ymm0
vpminud (%rdx), %ymm0, %ymm1
vpcmpeqd%ymm1, %ymm0, %ymm1
vpblendvb   %ymm1, (%rdi), %ymm0, %ymm0
vmovdqu32   %ymm0, (%rdi)
vmovdqu32   32(%rsi), %ymm0
vpminud 32(%rdx), %ymm0, %ymm1
vpcmpeqd%ymm1, %ymm0, %ymm1
vpblendvb   %ymm1, 32(%rdi), %ymm0, %ymm0
vmovdqu32   %ymm0, 32(%rdi)
vzeroupper


But there is mask register in avx512f, it could be better as:

vmovdqu   (%rsi), %ymm0 #5.25
vmovdqu   32(%rsi), %ymm1   #5.25
vpcmpud   $6, (%rdx), %ymm0, %k1#5.25
vpcmpud   $6, 32(%rdx), %ymm1, %k2  #5.25
vmovdqu32 %ymm0, (%rdi){%k1}#5.6
vmovdqu32 %ymm1, 32(%rdi){%k2}  #5.6
vzeroupper  #6.1
ret #6.1

That's because currently gcc only hanlde 512-bit vector
=---
 3437  /* In AVX512F the result of comparison is an integer mask.  */   
 3438  bool maskcmp = false;
 3439  rtx x;   
 3440   
 3441  if (GET_MODE_SIZE (cmp_ops_mode) == 64)  
 3442{  
 3443  unsigned int nbits = GET_MODE_NUNITS (cmp_ops_mode); 
 3444  cmp_mode = int_mode_for_size (nbits, 0).require ();  
 3445  maskcmp = true;  
 3446}  
 3447  else  


With additional -mprefer-vector-width=512, gcc have 

vmovdqu32   (%rsi), %zmm0
vpminud (%rdx), %zmm0, %zmm1
vpcmpeqd%zmm1, %zmm0, %k1
vmovdqu32   (%rdi), %zmm0{%k1}
vmovdqu32   %zmm0, (%rdi)
vzeroupper
ret

Since mask register is related to isa not vector size, under avx512f we can
also have 128/256-bit vector condition move.

[Bug ipa/92685] In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers

[erick.oc...@theobroma-systems.com]

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

--- Comment #1 from Erick Ochoa  ---
Created attachment 47368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47368&action=edit
Test Cases

[Bug ipa/92685] New: In IPA's execute stage create_version_clone_with_body fails with non-vNULL callers

[erick.oc...@theobroma-systems.com]

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

Bug ID: 92685
   Summary: In IPA's execute stage create_version_clone_with_body
fails with non-vNULL callers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erick.oc...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47367&action=edit
Hello World IPA pass with call to create_version_clone_with_body

Hello,

I am developing a simple ipa pass that versions a single call site to method
`bar`.

I am using `create_version_clone_with_body` instead of `create_version_clone`
because I want to modify `foo`'s body.

In my test case I have three functions
* main
* foo
* bar

In my simple ipa pass, I have implemented the execute stage to call
`create_version_clone_with_body` for method bar.
I am compiling my test with -flto-partition=none, which if I understand
correctly means the execution stage should have access to the method bodies.

You can apply the patch to master (commit id:
17a2c588c29f089d3c2a36df47175bbdf376e399)

I also add my test case.
After compiling with my patch, to trigger the bug just modify the Makefile to
point to the version of gcc with the patch and `make`.

[Bug c/92684] bitfield behavior not matching the declared type

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
There is a defect report dealing with this in C and such.
Both are correct for C11 but would be incorrect for C90 which defines bit-field
types because of the defect report.  GCC decided to follow the C90 way because
it is easier to implement one way for both.

[Bug c/92684] bitfield behavior not matching the declared type

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
bit-fields in C is a type.
while in C++, it is not.

So:
st.v2 << 3

This is not ((long)st.v2) << 3 but rather (long:45)<<3.  So it gets truncated.

C11:
fff8
0xfff8
1ffffff8
1 2 8000

C++14:
fff8
0xfff8
fff8
1 2 8000

[Bug c/92684] bitfield behavior not matching the declared type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
-W -Wall:
t.c: In function ‘main’:
t.c:40:3: warning: left shift count >= width of type [enabled by default]
   printf("%lx %lx %lx\n", b.bit1, b.bit1 << 1, b.bit1 << 63);
   ^
t.c:40:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
but argument 2 has type ‘int’ [-Wformat=]
t.c:40:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
but argument 3 has type ‘int’ [-Wformat=]
t.c:40:3: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
but argument 4 has type ‘int’ [-Wformat=]

[Bug c/92684] New: bitfield behavior not matching the declared type

[wuxb45 at gmail dot com]

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

Bug ID: 92684
   Summary: bitfield behavior not matching the declared type
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wuxb45 at gmail dot com
  Target Milestone: ---

found wrong data when compiled by gcc 9.2.0 (x86_64, -std=gnu11). Have not
tried other gcc versions. The results are correct on clang 8.0.1.

Long story short: some bits are missing when using bitfields with uint64_t as
the declared type. Maybe I should use a (u64) cast on every dereference to
those fields. But the results are not always wrong. Maybe I should read some
C11 specs. But consider the different behaviors between gcc and clang, I decide
to report a bug here in hope to get some better help. Thanks.

This reproduces the results: gcc/clang -std=gnu11 main.c

#include 
#include 
#include 
typedef uint64_t u64;

struct st {
  union {
struct {
  u64 v1:19;
  u64 v2:45;
};
void * ptr;
  };
};

struct bits {
  u64 bit1:1;
  u64 bitx:63;
};

  int
main(void)
{
  char * val = "0xfff8";
  // x has 48 valid bits, the three low bits are 0s
  volatile u64 x = strtoull(val, NULL, 16);
  printf("%lx\n", x);
  // st stores that 45 bits
  struct st st = {.v1 = 0, .v2 = (x >> 3)};
  printf("%p\n", st.ptr);
  // y should get the original bits; but the three high bits are gone.
  u64 y = st.v2 << 3;
  printf("%lx\n", y);


  // this is another (minor) related case.
  // some are correct and some are wrong.
  struct bits b = {.bit1 = 1, .bitx = 0};
  // this is more interesting. gcc shows "8000", clang shows "1"
  printf("%lx %lx %lx\n", b.bit1, b.bit1 << 1, b.bit1 << 63);
  return 0;
}

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #14 from Jerry DeLisle  ---
Fixed on 10, 9, and 8.

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Nov 27 00:50:51 2019
New Revision: 278753

URL: https://gcc.gnu.org/viewcvs?rev=278753&root=gcc&view=rev
Log:
2019-11-26  Jerry DeLisle  

Backport from mainline
PR fortran/92100
io/transfer.c (data_transfer_init): Use fbuf_reset
instead of fbuf_flush before the seek. Note that fbuf_reset
calls fbuf_flush and adjusts fbuf pointers.

gfortran.dg/streamio_18.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/streamio_18.f90
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/io/transfer.c

[Bug debug/92664] Wrong .debug_line section information when compiling stdin input with -g3

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 27 00:23:39 2019
New Revision: 278752

URL: https://gcc.gnu.org/viewcvs?rev=278752&root=gcc&view=rev
Log:
PR debug/92664
* dwarf2out.c (lookup_filename): Use "" instead of "".

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

[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Fixed in r278742.

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

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

Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal 
substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683

   What|Removed |Added

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

[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Tue Nov 26 23:56:22 2019
New Revision: 278742

URL: https://gcc.gnu.org/viewcvs?rev=278742&root=gcc&view=rev
Log:
PR tree-optimization/92683 - strncmp incorrect result with equal substrings and
non-const bound

gcc/testsuite/ChangeLog:

PR tree-optimization/92683
* gcc.dg/strcmpopt_8.c: New test.
* gcc.dg/strcmpopt_9.c: New test.

gcc/ChangeLog:

PR tree-optimization/92683
* gimple-fold.c (gimple_fold_builtin_string_compare): Restore a test
inadvertently removed in a previous change.  Rename local variable
for clarity.

Added:
trunk/gcc/testsuite/gcc.dg/strcmpopt_8.c
trunk/gcc/testsuite/gcc.dg/strcmpopt_9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug c/92671] gcc/c/c-parser.c: minor ( and ) tidyup

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I don't think this is a confusing case of precedence, i.e. the proposed 
change is not an improvement.

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Nov 26 22:56:24 2019
New Revision: 278740

URL: https://gcc.gnu.org/viewcvs?rev=278740&root=gcc&view=rev
Log:
2019-11-26  Jerry DeLisle  

Backport from mainline
PR fortran/92100
io/transfer.c (data_transfer_init_worker): Use fbuf_reset
instead of fbuf_flush before the seek. Note that fbuf_reset
calls fbuf_flush and adjusts fbuf pointers.

gfortran.dg/streamio_18.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/streamio_18.f90
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/libgfortran/ChangeLog
branches/gcc-9-branch/libgfortran/io/transfer.c

[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The failure doesn't seem to be reliably reproducible.  Of the three times the
script below runs the test it fails just once.

$ for i in 1 2 3; do nice time make -C /build/gcc-git-svn/gcc check-c 
'CFLAGS=-O0 -g3' 'CXXFLAGS=-O0 -g3' 'STAGE1_CFLAGS=-O0 -g3'
'STAGE1_CXXFLAGS=-O0 -g3' RUNTESTFLAGS="dg.exp=Warray-bounds-22.c
--target_board=unix/-m32"; done
make: Entering directory '/ssd/build/gcc-git-svn/gcc'
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/ssd/build/gcc-git-svn/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /src/gcc/git-svn/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gcc-parallel/finished ]; then \
  rm -rf testsuite/gcc; \
else \
  cd testsuite/gcc; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
dg.exp=Warray-bounds-22.c --target_board=unix/-m32; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by msebor on Tue Nov 26 15:39:30 2019
Native configuration is x86_64-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
unix/-m32

Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /src/gcc/git-svn/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /src/gcc/git-svn/gcc/testsuite/gcc.dg/dg.exp ...

=== gcc Summary ===

# of expected passes15
# of expected failures  8
/ssd/build/gcc-git-svn/gcc/xgcc  version 10.0.0 20191126 (experimental) (GCC) 

make[1]: Leaving directory '/ssd/build/gcc-git-svn/gcc'
make: Leaving directory '/ssd/build/gcc-git-svn/gcc'
0.63user 0.14system 0:00.94elapsed 83%CPU (0avgtext+0avgdata 39292maxresident)k
0inputs+128outputs (0major+60721minor)pagefaults 0swaps
make: Entering directory '/ssd/build/gcc-git-svn/gcc'
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/ssd/build/gcc-git-svn/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /src/gcc/git-svn/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gcc-parallel/finished ]; then \
  rm -rf testsuite/gcc; \
else \
  cd testsuite/gcc; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
dg.exp=Warray-bounds-22.c --target_board=unix/-m32; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by msebor on Tue Nov 26 15:39:31 2019
Native configuration is x86_64-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
unix/-m32

Running target unix/-m32
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /src/gcc/git-svn/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /src/gcc/git-svn/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Warray-bounds-22.c vla (test for warnings, line 67)
FAIL: gcc.dg/Warray-bounds-22.c vla (test for warnings, line 69)

=== gcc Summary ===

# of expected passes13
# of unexpected failures2
# of expected failures  8
/ssd/build/gcc-git-svn/gcc/xgcc  version 10.0.0 20191126 (experimental) (GCC) 

make[1]: Leaving directory '/ss

[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-26
 Blocks||83819
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1


Referenced Bugs:

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

[Bug tree-optimization/92683] New: [10 Regression] strncmp incorrect result with equal substrings and non-const bound

[msebor at gcc dot gnu.org]

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

Bug ID: 92683
   Summary: [10 Regression] strncmp incorrect result with equal
substrings and non-const bound
   Product: gcc
   Version: 10.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: ---

r278621 introduced a bug where a non-constant bound in calls to strncmp is
treated incorrectly as if it were a constant greater than the length of either
argument.

$ cat t.c && gcc -O1 -S -Wall -Wextra -Wunused
-fdump-tree-forwprop1=/dev/stdout t.c
int f (void)
{
  return __builtin_strncmp ("123", "1234", 3);   // correctly folded to zero
}

int g (void)
{
  int n = 3;
  return __builtin_strncmp ("123", "1234", n);   // incorrectly folded to -1
}


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

f ()
{
   :
  return 0;

}



;; Function g (g, funcdef_no=1, decl_uid=1933, cgraph_uid=2, symbol_order=1)

g ()
{
  int n;

   :
  return -1;

}

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Nov 26 22:11:39 2019
New Revision: 278738

URL: https://gcc.gnu.org/viewcvs?rev=278738&root=gcc&view=rev
Log:
Update vect_char_add target selector to use its own cache

This patch updates the vect_char_add target selector to use its own
cache instead of the vect_int cache.

This was causing a situation where bb-slp-40.c would fail on sparc when
run after other tests that use the vect_int target selector, but pass
when run on its own.

2019-11-26  Joel Hutton  

gcc/testsuite/
PR testsuite/92391
* lib/target-supports.exp (check_effective_target_vect_char_add):
Use a separate cache entry from vect_int.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug c++/92648] Handling of unknown attributes

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 26 21:58:22 2019
New Revision: 278737

URL: https://gcc.gnu.org/viewcvs?rev=278737&root=gcc&view=rev
Log:
PR c++/92648
* parser.c (cp_parser_std_attribute): For unknown attributes,
skip balanced token seq instead of trying to parse
attribute-argument-clause as expression list.  Formatting fix.

* g++.dg/cpp0x/gen-attrs-71.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-71.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
Author: jakub
Date: Tue Nov 26 21:57:27 2019
New Revision: 278736

URL: https://gcc.gnu.org/viewcvs?rev=278736&root=gcc&view=rev
Log:
PR c++/61414
* c-attribs.c (handle_mode_attribute): Add mode attribute to
ENUMERAL_TYPEs.

* class.c (enum_to_min_precision): New hash_map.
(enum_min_precision): New function.
(check_bitfield_decl): Use it.

* g++.dg/cpp0x/enum23.C: Remove xfail.
* g++.dg/cpp0x/enum28.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum38.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/enum23.C

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---

> Modified:
> trunk/gcc/ChangeLog

Hi hit the wrong log file for the testsuite entry. It has been fixed.

[Bug target/92682] [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-11-26
 CC||seurer at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Hmmm... seems like a local problem with the test result setup. I can
not reproduce this on gcc135.fsffrance.org.

Bill, since I based this on your results (possibly prematurely): Could
you maybe check your setup what is going on here?

[Bug c++/48078] accepts-invalid: taking address of private member function from template function

[fkostenzer at live dot at]

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

fkostenzer at live dot at changed:

   What|Removed |Added

 CC||fkostenzer at live dot at

--- Comment #6 from fkostenzer at live dot at ---
This can also be triggered on gcc 9 using
```
class A
{
int foo() const { return 42; }
};

template
struct B : public A
{
static constexpr auto member_fn = &B::foo;
};

int main()
{
return (A().*B<>::member_fn)();
}
```

running `g++ -std=c++17 -O2 -Wall -Wextra` produces
main:
mov eax, 42
ret

[Bug target/92682] New: [10 Regression] maxlocval_4.f90 / minlocval_4.f90 failure on POWER9

[tkoenig at gcc dot gnu.org]

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

Bug ID: 92682
   Summary: [10 Regression] maxlocval_4.f90 / minlocval_4.f90
failure on POWER9
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-testresults/2019-10/msg01757.html (r277518)
has

FAIL: gfortran.dg/maxlocval_4.f90   -O2  execution test
FAIL: gfortran.dg/minlocval_4.f90   -O2  execution test

while https://gcc.gnu.org/ml/gcc-testresults/2019-10/msg01701.html
(r277488) appears clean.

It appears to be specific to POWER9, POWER7 and POWER8 do not
appear to have that particular failure.

I'll look for a bit (this is one of my test cases).

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe  ---
the patch at comment #5 works for powerpc-darwin9, test output looks "nominal"
(given that there's a lot of recent regression/new fails anyway)

[Bug c/92673] OCaml fails to link with recent trunk

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jürgen Reuter from comment #2)
> (In reply to Richard Biener from comment #1)
> > Try -fcommon, it's default recently was swapped to -fno-common.
> 
> The default for gcc was changed? Which commit was this? I cannot find any
> reference in the ChangeLog.

https://gcc.gnu.org/ml/gcc-cvs/2019-11/msg00825.html

[Bug c++/92642] Enhance shift-count-overflow output

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jonny Grant from comment #4)
> This test case for similar does have a nice warning.
> 
> Interestingly, G++ does not indicate that 5147483647 is already 34 bits long:
> 100110010110101011101
> which is more than an 'int' (32bit) which as Jonathan has highlighted, to be
> the way numbers are treated in C/C++ when they do not have UL suffix.

C changed with C99 and C++ changed with C++11 (IIRC) when it comes to literals.

[Bug fortran/81205] Hybrid MPI and OpenMp: Blocking code in loops

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> > I will try and will let you now.
> 
> Any progress?

No progress in 2.5 years.  Closing as invalid.

[Bug other/92681] New: PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean is not training non-C++ frontends

[hubicka at gcc dot gnu.org]

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

Bug ID: 92681
   Summary: PGO bootstrap is broken with
--with-build-config=bootstrap-lto-lean is not training
non-C++ frontends
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This definitly leads to suboptimal compile time experience with Ada, Fortran,
go, etc.

[Bug bootstrap/92680] New: PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr

[hubicka at gcc dot gnu.org]

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

Bug ID: 92680
   Summary: PGO bootstrap is broken with
--with-build-config=bootstrap-lto-lean and in-itree
mpfr
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Build with bootstrap-lto-lean with in-tree mpfr fails in profile mismatch on
set_d.o.  This is caused by fact that mpfr actually misconfigures itself with
LTO. Its configure script scans assembly to detect format of long double and
this gives wrong answer with LTO leading to suboptimal configuration.

[Bug sanitizer/92678] UB sanitizer and pointer to member functions with multiple inheritance

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The problem is that the PMF call is maybe instrumented too late, during
genericization the first argument is (struct C *) obj + (sizetype) pmf.__delta
and so -fsanitize=vptr decides that it should check whether *((struct C *) obj
+ (sizetype) pmf.__delta) has dynamic type C, but it should really check that
*obj has dynamic type C, or perhaps that *((struct C *) obj + (sizetype)
pmf.__delta) has dynamic type B2.  clang++ seems to check the former.
The question is if it is possible to figure this out from the lowered code that
has been through cp_fold already and the pmf could be all kinds of weird
expressions, or if we need to move the instrumentation earlier.

gcc-bugs@gcc.gnu.org

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-26
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=69373
 Ever confirmed|0   |1

[Bug c++/92679] Test case with failing unordered_map search when key is type_index

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Or simply:

  template 
  void accept(F f) {
functions[std::type_index(typeid(TArg))]
  = [f](std::any &x) -> TReturn { return f(std::any_cast(x)); };
  }

[Bug c++/92659] Suggestions for bitshift

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

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

[Bug c++/92679] Test case with failing unordered_map search when key is type_index

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Change the capture from [&f] to simply [f] and it works fine.

[Bug c++/92679] Test case with failing unordered_map search when key is type_index

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Non-preprocessed testcase:

#include 
#include 
#include 
#include 
#include 

template 
struct any_visitor {
  using function = std::function;
  std::unordered_map functions;

  template 
  void accept(std::function f) {
functions.insert(std::make_pair(std::type_index(typeid(TArg)),
function([&f](std::any &x) -> TReturn {
  return f(std::any_cast(x));
})));
  }

  TReturn operator()(std::any &x) {
try {
  auto function = functions.at(std::type_index(x.type()));

  return function(x);
} catch (...) {
  throw std::runtime_error("No visitor registered");
}
  }
};

int main() {
  auto visitor = any_visitor();

  visitor.accept([](int x) { return std::to_string(x); });
  visitor.accept([](double x) { return std::to_string(x); });
  visitor.accept([](std::string &x) { return x; });
  visitor.accept>(
  [](std::vector&) { return "VECTOR"; });

  std::any x;

  x = 1;
  std::cout << visitor(x) << "\n";

  x = 1.;
  std::cout << visitor(x) << "\n";

  x = std::string("STRING");
  std::cout << visitor(x) << "\n";

  x = std::vector{0., 1., 2., 3., 4., 5.};
  std::cout << visitor(x) << "\n";
}

The bug is here:

  void accept(std::function f) {
functions.insert(std::make_pair(std::type_index(typeid(TArg)),
function([&f](std::any &x) -> TReturn {
 

You're binding a reference to a function parameter, which goes out of scope as
soon as the function returns. When you later invoke the std::function it uses a
dangling reference.

[Bug c++/92679] Test case with failing unordered_map search when key is type_index

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Without optimisation it prints your expected output for me (with any version of
GCC). It only fails with optimisation.

ASan seems to show a problem in your code:

==428329==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7ffcfe3b22f0 at pc 0x004060c0 bp 0x7ffcfe3b1be0 sp 0x7ffcfe3b1bd8
READ of size 8 at 0x7ffcfe3b22f0 thread T0
#0 0x4060bf in std::_Function_base::_M_empty() const
/home/jwakely/gcc/8/include/c++/8.3.1/bits/std_function.h:260
#1 0x4060bf in std::function, std::allocator > (int&)>::operator()(int&) const
/home/jwakely/gcc/8/include/c++/8.3.1/bits/std_function.h:685
#2 0x4060bf in any_visitor, std::allocator >
>::accept(std::function, std::allocator >
(int&)>)::{lambda(std::any&)#1}::operator()(std::any&) const /tmp/92679.cc:18
#3 0x4060bf in std::_Function_handler, std::allocator > (std::any&),
any_visitor,
std::allocator >
>::accept(std::function, std::allocator >
(int&)>)::{lambda(std::any&)#1}>::_M_invoke(std::_Any_data const&, std::any&)
/home/jwakely/gcc/8/include/c++/8.3.1/bits/std_function.h:283
#4 0x407187 in std::function, std::allocator >
(std::any&)>::operator()(std::any&) const
/home/jwakely/gcc/8/include/c++/8.3.1/bits/std_function.h:687
#5 0x407187 in any_visitor, std::allocator > >::operator()(std::any&)
/tmp/92679.cc:26
#6 0x4032d0 in main /tmp/92679.cc:45
#7 0x7fe45c0001a2 in __libc_start_main ../csu/libc-start.c:308
#8 0x4023cd in _start (/tmp/a.out+0x4023cd)

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
https://gcc.gnu.org/ml/gcc-patches/2010-04/msg00895.html
contained documentation but in the end we went with an internal "fn spec"
attribute rather than user visible fnspec:
https://gcc.gnu.org/ml/gcc-patches/2010-05/msg00383.html

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[burnus at gcc dot gnu.org]

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

--- Comment #17 from Tobias Burnus  ---
(In reply to Thomas Koenig from comment #16)
> Is there a specification (or even description) for fn spec somewhere?
> I can't say I understand exactly what it does.

Maybe gimple.c's gimple_call_arg_flags:
case 'x':
case 'X':
  return EAF_UNUSED;

case 'R':
  return EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE;

case 'r':
  return EAF_NOCLOBBER | EAF_NOESCAPE;

case 'W':
  return EAF_DIRECT | EAF_NOESCAPE;

case 'w':
  return EAF_NOESCAPE;

case '.':
default:
  return 0;

+ tree-into-ssa.c's pass_build_ssa::execute
  if (TREE_STRING_POINTER (fnspec)[i]  == 'R'
  || TREE_STRING_POINTER (fnspec)[i] == 'r')
{
  tree name = ssa_default_def (fun, arg);
  if (name)
SSA_NAME_POINTS_TO_READONLY_MEMORY (name) = 1;
}

+ decl_return_flags in calls.c:
  switch (TREE_STRING_POINTER (attr)[0])
{
case '1':
case '2':
case '3':
case '4':
  return ERF_RETURNS_ARG | (TREE_STRING_POINTER (attr)[0] - '1');

case 'm':
  return ERF_NOALIAS;

case '.':
default:
  return 0;
}

The constants are defined in tree-core.h.

The name 'fn spec' contains a space to make it only internally available,
hence, also not well documented.

[Bug fortran/91944] [8/9/10 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6156

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/91944] [8/9/10 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6156

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-10-23 00:00:00 |2019-11-26
 CC||jakub at gcc dot gnu.org
   Target Milestone|10.0|8.4
Summary|[10 Regression] ICE in  |[8/9/10 Regression] ICE in
   |gfc_conv_array_initializer, |gfc_conv_array_initializer,
   |at  |at
   |fortran/trans-array.c:6156  |fortran/trans-array.c:6156
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Started with my r241630 change.

[Bug c++/92679] Test case with failing unordered_map search when key is type_index

[marcello.m at yahoo dot com]

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

--- Comment #1 from Marcello Mansueto  ---
Created attachment 47365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47365&action=edit
Preprocessed version of the file that triggers the bug

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #16 from Thomas Koenig  ---
Is there a specification (or even description) for fn spec somewhere?
I can't say I understand exactly what it does.

[Bug c++/92679] New: Test case with failing unordered_map search when key is type_index

[marcello.m at yahoo dot com]

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

Bug ID: 92679
   Summary: Test case with failing unordered_map search when key
is type_index
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcello.m at yahoo dot com
  Target Milestone: ---

Hello,

Attached files are from gcc 9.1.0 but I've tested earlier and later versions
using https://godbolt.org/ with the same results.

Expected output:
1
1.00
STRING
VECTOR

Actual output from 7.1 to 8.3:
VECTOR
VECTOR
VECTOR
VECTOR

Actual output from 9.1 and later:
Segmentation fault

Regards.

[Bug sanitizer/92678] New: UB sanitizer and pointer to member functions with multiple inheritance

[deng at randomsample dot de]

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

Bug ID: 92678
   Summary: UB sanitizer and pointer to member functions with
multiple inheritance
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: deng at randomsample dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Consider this example:

#include 

class B1 {
public:
int b1;
virtual void mf1() { std::cout << "b1=" << b1 << std::endl; }
};

class B2 {
public:
int b2;
virtual void mf2() { std::cout << "b2=" << b2 << std::endl; }
};

class C : public B1, public B2 { };

void call_memfun (C obj, void (C::*pmf)())
{
(obj.*pmf)();
}

int main()
{
C obj;
obj.b2=1;
call_memfun(obj, &C::mf2);
}


Compilation with gcc 9.2.1:

  g++ -Wall -g -fsanitize=undefined -o test test.cpp

Running 'test' results in the following output:

test.cpp:19:15: runtime error: member call on address 0x74d24610 which does
not point to an object of type 'C'
0x74d24600: note: object is base class subobject at offset 16 within object
of type 'C'
 01 00 00 00  28 30 40 00 00 00 00 00  b6 15 40 00 00 00 00 00  40 30 40 00 00
00 00 00  01 00 00 00
  ^
~~~
vptr for 'B2'
base class of 'C'

So the sanitizer complains that 'pmf' in 'call_memfun' is actually a pointer to
B2::mf2(), which looks like a false-positive warning to me? If 'C' only
inherits from 'B2', the warning disappears.

[Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-26
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug tree-optimization/92677] New: [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704

[marxin at gcc dot gnu.org]

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

Bug ID: 92677
   Summary: [10 Regression] ICE in get_group_load_store_type, at
tree-vect-stmts.c:2261 since r271704
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: alejandro at gcc dot gnu.org
  Target Milestone: ---

Starting from the following revision I see:

$ cat vect.i
int a, c;
int *b;
long d;
double *e;

void fn1() {
  long f;
  double g, h;
  while (c) {
if (d) {
  g = *e;
  *(b + 4) = g;
}
if (f) {
  h = *(e + 2);
  *(b + 6) = h;
}
e += a;
b += 8;
c--;
d += 2;
  }
}

$ gcc vect.i -c -mavx2 -O3
during GIMPLE pass: vect
vect.i: In function ‘fn1’:
vect.i:6:6: internal compiler error: in get_group_load_store_type, at
tree-vect-stmts.c:2261
6 | void fn1() {
  |  ^~~
0x7289ae get_group_load_store_type
../../gcc/tree-vect-stmts.c:2261
0x7289ae get_load_store_type
../../gcc/tree-vect-stmts.c:2475
0x1021b1a vectorizable_load
../../gcc/tree-vect-stmts.c:8717
0x1039905 vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*,
vec*)
../../gcc/tree-vect-stmts.c:10846
0x1051ef3 vect_analyze_loop_operations
../../gcc/tree-vect-loop.c:1608
0x1051ef3 vect_analyze_loop_2
../../gcc/tree-vect-loop.c:2139
0x1051ef3 vect_analyze_loop(loop*, vec_info_shared*)
../../gcc/tree-vect-loop.c:2554
0x1070ed4 try_vectorize_loop_1
../../gcc/tree-vectorizer.c:892
0x10718d9 vectorize_loops()
../../gcc/tree-vectorizer.c:1125
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/92659] Suggestions for bitshift

[jg at jguk dot org]

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

--- Comment #10 from Jonny Grant  ---
(In reply to Jonathan Wakely from comment #8)
> Because 5147483647 doesn't fit in an int, so it picks a larger type, because
> that's what the standard requires. 1 does fit in an int, so the compiler
> picks int, because that's what the standard requires.


Fair enough. Let's close this PR if no support for this suggestion.

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

[matz at gcc dot gnu.org]

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

--- Comment #6 from Michael Matz  ---
(In reply to Jonathan Wakely from comment #5)
> 
> Before choosing which conversion operator to use, the compiler considers the
> constructors of S, finding S(const S&) and S(S&&) as candidates. There is a
> viable conversion from Test&& to const S& and also one from Test&& to S&&.
> Both of those conversion sequences have conversion rank "user-defined"
> (because they use a user-defined conversion operator) but they use different
> conversion operators. Two different user-defined conversions are ambiguous,

Ah, it makes sense now ...

> it doesn't matter that one is a better match for being called on an rvalue.

... except may be this should matter ;-)  But it is as it is.

> The moveme(t).str() case is different, because there's no user-defined
> conversion. Overload resolution chooses which str() to call, and that *does*
> consider the ref-qualifiers when deciding which str() is a better match.

Right overload resolution vs. UCS, okay got it, many thanks :)

[Bug ipa/92676] [10 Regression] lto1: error: comdat-local function called by construct.constprop outside its comdat since r278669

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-26
  Known to work||9.2.0
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug c++/92675] sign-conversion C++ unsigned int j = -1;

[jg at jguk dot org]

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

--- Comment #2 from Jonny Grant  ---
(In reply to Jonathan Wakely from comment #1)
> That's an idiomatic way to get the largest unsigned value, it would be a
> shame if it warned.

Personally I would use UINT_MAX from limits.h, feels more idiomatic.

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

[matthijs at stdin dot nl]

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

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #14 from Matthijs Kooijman  ---
I actually think this is a different problem from the fixed
https://sourceware.org/bugzilla/show_bug.cgi?id=22502. Using gcc 8.2.1 and
binutils 2.31.51.20181213 from the STM32 Arduino core
(https://github.com/stm32duino/Arduino_Core_STM32), I can still reproduce this
problem using the example from comment 11 (and also in an actual implementation
using stm32duino). I also tested the example from the linked bug, which *is*
indeed fixed, leading me to believe this is a different problem (or the fix is
not complete yet).

The example from this bug is a lot bigger than the one from 22502, so there is
probably something in here that triggers this. Maybe that the weak
implementation is defined in assembly rather than C?

[Bug c++/92659] Suggestions for bitshift

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to David Brown from comment #6)
> All in all, the whole idea sounds counter-productive to me.  If you need
> spoon-feeding about the details of C here, you would be better off reading a
> book on the language than using trial and error and guessing from compiler
> messages.  And if you don't need spoon-feeding but just made a little
> mistake in your code (as we all do on occasion), then the current warning is
> fine.

^ This.

[Bug c++/92659] Suggestions for bitshift

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Because 5147483647 doesn't fit in an int, so it picks a larger type, because
that's what the standard requires. 1 does fit in an int, so the compiler picks
int, because that's what the standard requires.

[Bug c++/92659] Suggestions for bitshift

[jg at jguk dot org]

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

--- Comment #7 from Jonny Grant  ---
(In reply to David Brown from comment #4)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Is it appropriate?
> > > 
> > > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> > > believe there is some platform where "1ull" is necessary.
> > > 
> > > Maybe I'm wrong.  But if I'm correct, suggesting "1ul" is encouraging bad
> > > code.  I'll use "(size_t) 1 << 32" for this.
> > 
> > UL means Unsigned Long, so if that type is also 64bit like size_t, then it
> > is fine.
> > 
> > 
> > I would rather use the real type, if the compiler is too stupid to start
> > with a type big enough...  the same code with 5147483647 works fine, because
> > the compiler starts with the number as a 'long int' which is already 64bit,
> > no suffix required.
> > 
> 
> I recommend you learn the details of how C works before declaring the
> compiler "stupid".  This sort of thing is not up to the compiler.  When you
> write "1 << 32", the "1" is of type "int".  The compiler is not allowed to
> choose a different type - the best it can do is give you a warning.  And the
> compiler already /does/ give a warning - a perfectly good warning.  It is
> not the compiler's job to teach you how to program in C.

Hi David,
Compiler manages it okay with this example below. Therefore the compiler
appears to be allowed to choose 'long int' for the number being shifted in this
test case.

#include 
size_t i = 5147483647 << 2;

[Bug c++/67960] [8/9/10 Regression] Prefixing a function with [[deprecated]] produces multiple warnings

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||euloanty at live dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 92670 has been marked as a duplicate of this bug. ***

[Bug c++/92670] Same warning message duplicates for C++20 "deprecated" attribute

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79078
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
As requested by https://gcc.gnu.org/bugs/ please provide a complete testcase,
your example doesn't even compile. 

Here's a proper testcase:

struct sha1;

[[deprecated("old")]]
void flush(sha1&);

void f(sha1& s)
{
  flush(s);
}

This prints:

depr.cc: In function 'void f(sha1&)':
depr.cc:8:10: warning: 'void flush(sha1&)' is deprecated: old
[-Wdeprecated-declarations]
8 |   flush(s);
  |  ^
depr.cc:4:6: note: declared here
4 | void flush(sha1&);
  |  ^
depr.cc:8:10: warning: 'void flush(sha1&)' is deprecated: old
[-Wdeprecated-declarations]
8 |   flush(s);
  |  ^
depr.cc:4:6: note: declared here
4 | void flush(sha1&);
  |  ^


I think this is a dup of PR 67960

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

[Bug ipa/92676] [10 Regression] lto1: error: comdat-local function called by construct.constprop outside its comdat since r278669

[marxin at gcc dot gnu.org]

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

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

[Bug ipa/92676] [10 Regression] lto1: error: comdat-local function called by construct.constprop outside its comdat since r278669

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 47363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47363&action=edit
1.ii

[Bug ipa/92676] New: [10 Regression] lto1: error: comdat-local function called by construct.constprop outside its comdat since r278669

[marxin at gcc dot gnu.org]

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

Bug ID: 92676
   Summary: [10 Regression] lto1: error: comdat-local function
called by construct.constprop outside its comdat since
r278669
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Since the revision, I see the following ICE:

$ g++ -O2 -flto=auto -fPIC -DPIC -c 1.ii -o x.o && g++ 2.ii x.o
1.ii:169:5: warning: ‘xmlrpc_c::value_struct::operator
std::map, xmlrpc_c::value>()
const::cMemberWrapper::cMemberWrapper(int)’ used but never defined
  169 | cMemberWrapper(int);
  | ^~
/usr/bin/ld: x.o (symbol from plugin): in function `std::piecewise_construct':
(.text+0x0): multiple definition of `std::piecewise_construct';
/tmp/ccuP4DF0.o:(.bss+0x0): first defined here
lto1: error: comdat-local function called by construct.constprop outside its
comdat
_ZNSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN8xmlrpc_c5valueEEC2IJRS6_EJEEESt21piecewise_construct_tSt5tupleIJDpT_EESD_IJDpT0_EE.isra.0/49
(__ct_base .isra) @0x7f1faa6f02c0
  Type: function definition analyzed
  Visibility:
comdat_group:_ZNSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN8xmlrpc_c5valueEEC5IJRS6_EJEEESt21piecewise_construct_tSt5tupleIJDpT_EESD_IJDpT0_EE
  Same comdat group as:
_ZNSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN8xmlrpc_c5valueEEC2IJRS6_EJEEESt21piecewise_construct_tSt5tupleIJDpT_EESD_IJDpT0_EE/15
  References: 
  Referring: 
  Read from file: x.o
  Clone of
_ZNSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN8xmlrpc_c5valueEEC2IJRS6_EJEEESt21piecewise_construct_tSt5tupleIJDpT_EESD_IJDpT0_EE/15
  Availability: local
  Function flags: count:1073741824 (estimated locally) local
  Called by: construct.constprop/46 (1073741824 (estimated locally),1.00 per
call) (can throw external) 
  Calls: get/30 (1073741824 (estimated locally),1.00 per call) (can throw
external) forward/31 (1073741824 (estimated locally),1.00 per call) (can throw
external) __ct_comp /32 (1073741824 (estimated locally),1.00 per call) (can
throw external) 
during IPA pass: sra
lto1: internal compiler error: verify_cgraph_node failed
0x887cbe cgraph_node::verify_node()
../../gcc/cgraph.c:3411
0x87a60c symtab_node::verify()
../../gcc/symtab.c:1268
0x87bd7f symtab_node::verify_symtab_nodes()
../../gcc/symtab.c:1288
0xaeb00f symtab_node::checking_verify_symtab_nodes()
../../gcc/cgraph.h:648
0xaeb00f symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/ipa.c:672
0xbecd09 execute_todo
../../gcc/passes.c:2051
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Michael Matz from comment #4)
> the return value of moveme() has type Test&&.  There exists a conversion
> operator exactly matching that type,

See Bug 86521 comment 4, it's similar here.

Before choosing which conversion operator to use, the compiler considers the
constructors of S, finding S(const S&) and S(S&&) as candidates. There is a
viable conversion from Test&& to const S& and also one from Test&& to S&&. Both
of those conversion sequences have conversion rank "user-defined" (because they
use a user-defined conversion operator) but they use different conversion
operators. Two different user-defined conversions are ambiguous, it doesn't
matter that one is a better match for being called on an rvalue.

The moveme(t).str() case is different, because there's no user-defined
conversion. Overload resolution chooses which str() to call, and that *does*
consider the ref-qualifiers when deciding which str() is a better match.

[Bug bootstrap/92235] [10 Regression] ICE in host_detect_local_cpu, segfault (profiled lto) on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
That line was:
  if (pass && (flags & ECF_MALLOC))
{
  rtx temp = gen_reg_rtx (GET_MODE (valreg));
^^^ this one.
  rtx_insn *last, *insns;
ICE there would mean we have an ECF_MALLOC call with void reutrn value, but I
think that is both quite unlikely in GCC sources and handle_malloc_attribute
wouldn't have created it.

[Bug c++/92659] Suggestions for bitshift

[david at westcontrol dot com]

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

--- Comment #6 from David Brown  ---
(In reply to Xi Ruoyao from comment #3)
> (In reply to Jonny Grant from comment #2)
> > (In reply to Xi Ruoyao from comment #1)
> > > Is it appropriate?
> > > 
> > > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> > > believe there is some platform where "1ull" is necessary.
> > > 
> > > Maybe I'm wrong.  But if I'm correct, suggesting "1ul" is encouraging bad
> > > code.  I'll use "(size_t) 1 << 32" for this.
> > 
> > UL means Unsigned Long, so if that type is also 64bit like size_t, then it
> > is fine.
> 
> That is true on *your platform*.
> 
> I can't find any specification in C standard saying "the bitwidth of long
> should >= the bitwidth of size_t".  So at least theoretically it may be
> insufficient.
> 
> Writing unportable thing is OK (if you don't care about other platforms) but
> *suggesting* unportable thing is bad.

There is no requirement for "size_t" to be of any particular size in relation
to the other integer types.  On 64-bit Windows, for example, size_t is 64 bits
but unsigned long is 32 bits.

So there is no portable integer constant suffix that would suit for "size_t".

However, the "size_t" here is a red herring - the problem is that the
expression "1 << 32" overflows, but it would not overflow if the "1" was of a
64 bit type.  The most portable choice here would be "1ull" or "1ll" (the
compiler has no way to guess which you want).  But that would not work with
pre-C99 standards.

All in all, the whole idea sounds counter-productive to me.  If you need
spoon-feeding about the details of C here, you would be better off reading a
book on the language than using trial and error and guessing from compiler
messages.  And if you don't need spoon-feeding but just made a little mistake
in your code (as we all do on occasion), then the current warning is fine.

[Bug c++/92675] sign-conversion C++ unsigned int j = -1;

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  ---
That's an idiomatic way to get the largest unsigned value, it would be a shame
if it warned.

[Bug c++/92659] Suggestions for bitshift

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Xi Ruoyao from comment #3)
> I can't find any specification in C standard saying "the bitwidth of long
> should >= the bitwidth of size_t".  So at least theoretically it may be
> insufficient.

Right. Also size_t itself might only be 32 bits, so (size_t) 1 << 32 is no
better than 1 << 32.

I don't think this suggestion is a good idea.

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[joel.hutton at arm dot com]

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

--- Comment #11 from Joel Hutton  ---
I see, I think you're right. I was able to replicate the failure when running
the whole 'vect' testsuite. I tried the following change:

diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 5fe1e83492c..a4418a31516 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5753,7 +5753,7 @@ proc check_effective_target_vect_bswap { } {
 # one vector length.

 proc check_effective_target_vect_char_add { } {
-return [check_cached_effective_target_indexed vect_int {
+return [check_cached_effective_target_indexed vect_char_add {
   expr {
  [istarget i?86-*-*] || [istarget x86_64-*-*]
  || ([istarget powerpc*-*-*]


which appeared to work, however I'm not familiar with how
check_cached_effective_target_indexed works, so I'm not sure if this is
sufficient.

[Bug c++/92659] Suggestions for bitshift

[david at westcontrol dot com]

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

David Brown  changed:

   What|Removed |Added

 CC||david at westcontrol dot com

--- Comment #4 from David Brown  ---
(In reply to Jonny Grant from comment #2)
> (In reply to Xi Ruoyao from comment #1)
> > Is it appropriate?
> > 
> > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> > believe there is some platform where "1ull" is necessary.
> > 
> > Maybe I'm wrong.  But if I'm correct, suggesting "1ul" is encouraging bad
> > code.  I'll use "(size_t) 1 << 32" for this.
> 
> UL means Unsigned Long, so if that type is also 64bit like size_t, then it
> is fine.
> 
> 
> I would rather use the real type, if the compiler is too stupid to start
> with a type big enough...  the same code with 5147483647 works fine, because
> the compiler starts with the number as a 'long int' which is already 64bit,
> no suffix required.
> 

I recommend you learn the details of how C works before declaring the compiler
"stupid".  This sort of thing is not up to the compiler.  When you write "1 <<
32", the "1" is of type "int".  The compiler is not allowed to choose a
different type - the best it can do is give you a warning.  And the compiler
already /does/ give a warning - a perfectly good warning.  It is not the
compiler's job to teach you how to program in C.

[Bug libgomp/92315] [10 regression] libgomp.c/pr58392.c and several others FAIL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
I think this should be fixed by r277964.  Please reopen if not.

[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

I think the right fix is to change comparison mode only if it is from and to
scalar integral mode.  If imode == omode, this code isn't reached, and it looks
completely wrong to say change comparison with DImode to V8QImode etc.

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Joel Hutton  ---
> Weird, I tested on gcc202.
[...]
> # of unsupported tests  2

I see the same when testing this single test individually.  However,
within a full parallel test run, the test *is* run.

Unless I'm very much mistaken, the problem is that
check_effective_target_vect_char_add uses the same cache as
check_effective_target_vect_int (vect_int), which *is* supported on
sparc*-*-*, so depending on which of the two effective-target keyworks
happens to be used first affects which tests are run.

[Bug c++/92659] Suggestions for bitshift

[xry111 at mengyan1223 dot wang]

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

--- Comment #3 from Xi Ruoyao  ---
(In reply to Jonny Grant from comment #2)
> (In reply to Xi Ruoyao from comment #1)
> > Is it appropriate?
> > 
> > Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> > believe there is some platform where "1ull" is necessary.
> > 
> > Maybe I'm wrong.  But if I'm correct, suggesting "1ul" is encouraging bad
> > code.  I'll use "(size_t) 1 << 32" for this.
> 
> UL means Unsigned Long, so if that type is also 64bit like size_t, then it
> is fine.

That is true on *your platform*.

I can't find any specification in C standard saying "the bitwidth of long
should >= the bitwidth of size_t".  So at least theoretically it may be
insufficient.

Writing unportable thing is OK (if you don't care about other platforms) but
*suggesting* unportable thing is bad.

[Bug c++/92659] Suggestions for bitshift

[jg at jguk dot org]

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

--- Comment #2 from Jonny Grant  ---
(In reply to Xi Ruoyao from comment #1)
> Is it appropriate?
> 
> Though on both 32-bit and 64-bit x86 "1ul" is good for a size_t, but I
> believe there is some platform where "1ull" is necessary.
> 
> Maybe I'm wrong.  But if I'm correct, suggesting "1ul" is encouraging bad
> code.  I'll use "(size_t) 1 << 32" for this.

UL means Unsigned Long, so if that type is also 64bit like size_t, then it is
fine.


I would rather use the real type, if the compiler is too stupid to start with a
type big enough...  the same code with 5147483647 works fine, because the
compiler starts with the number as a 'long int' which is already 64bit, no
suffix required.

#include 
int f()
{
size_t i = 1;
i = i << 32;
return i;
}

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[joel.hutton at arm dot com]

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

--- Comment #9 from Joel Hutton  ---
Weird, I tested on gcc202.

% uname -a
Linux gcc202 4.19.0-5-sparc64-smp #1 SMP Debian 4.19.37-6 (2019-07-18) sparc64
GNU/Linux

% cat gcc/testsuite/gcc/gcc.sum
Test run by joelh on Tue Nov 26 17:22:27 2019
Native configuration is sparc64-unknown-linux-gnu

=== gcc tests ===

Schedule of variations:
unix

Running target unix
Running /home/joelh/gcc/src/gcc/testsuite/gcc.dg/vect/vect.exp ...
UNSUPPORTED: gcc.dg/vect/bb-slp-40.c
UNSUPPORTED: gcc.dg/vect/bb-slp-40.c -flto -ffat-lto-objects

=== gcc Summary ===

# of unsupported tests  2
/home/joelh/gcc/objdir/gcc/xgcc  version 10.0.0 20191126 (experimental) (GCC)

[Bug c++/92675] New: sign-conversion C++ unsigned int j = -1;

[jg at jguk dot org]

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

Bug ID: 92675
   Summary: sign-conversion C++  unsigned int j = -1;
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Could G++ also give a nice error for -Wsign-conversion  ?
unsigned int j = -1;


GCC does already for C code, as does Clang C++



#1 with x86-64 gcc (trunk)
:1:18: warning: unsigned conversion from 'int' to 'unsigned int'
changes value from '-1' to '4294967295' [-Wsign-conversion]
1 | unsigned int j = -1;
  |  ^~


Clang gives a nice error with C++:
#1 with x86-64 clang (trunk)
:1:18: warning: implicit conversion changes signedness: 'int' to
'unsigned int' [-Wsign-conversion]
unsigned int j = -1;
 ~   ^~
1 warning generated.
Compiler returned: 0


Compiler returned: 1

[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-26
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r275959.  Slightly cleaned up testcase:
/* { dg-options "-O1 -ftree-loop-vectorize -fno-forward-propagate
-fno-tree-scev-cprop" } */

int v;

long int
foo (long int x)
{
  signed char i;

  for (i = 0; i < 8; ++i)
x |= !!v;

  return x + i;
}

The ICE happens during combine of
(insn 14 13 15 2 (set (subreg:DI (reg:V1DI 96 [ vect_x_12.7 ]) 0)
(ne:DI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr92510.c":9:7 701 {*setcc_di_1}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
into
(insn 15 14 16 2 (parallel [
(set (reg:DI 99)
(ior:DI (reg:DI 100)
(subreg:DI (reg:V1DI 96 [ vect_x_12.7 ]) 0)))
(clobber (reg:CC 17 flags))
]) "pr92510.c":11:12 454 {*iordi_1}
 (expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:V1DI 96 [ vect_x_12.7 ])
(nil)
subst creates there:
(ior:DI (subreg:DI (ne:V1DI (reg:CCZ 17 flags)
(const_int 0 [0])) 0)
(reg:DI 100))
if_then_else_cond then uses (const_int 1) as true and native_encode_rtx is
unhappy about trying to interpret a VOIDmode CONST_INT as something with
non-scalar mode (V1DImode).

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #47187|0   |1
is obsolete||

--- Comment #8 from Rainer Orth  ---
Created attachment 47361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47361&action=edit
32-bit sparc-sun-solaris2.11 bb-slp-40.c.162t.slp1

Current dump.

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-26
 Ever confirmed|0   |1

--- Comment #7 from Rainer Orth  ---
(In reply to Joel Hutton from comment #6)
> This should be fixed with Richard Sandifords changes.

Unfortunately, it isn't.  As of last night (r278688), I see

FAIL: gcc.dg/vect/bb-slp-40.c -flto -ffat-lto-objects  scan-tree-dump slp1
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/bb-slp-40.c scan-tree-dump slp1 "vectorizing stmts using SLP"

for both 32 and 64-bit.

[Bug c/92673] OCaml fails to link with recent trunk

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/92583] [8/9/10 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:15552

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|internal compiler error: in |[8/9/10 Regression]
   |tsubst_copy, at |internal compiler error: in
   |cp/pt.c:15552   |tsubst_copy, at
   ||cp/pt.c:15552

--- Comment #2 from Jakub Jelinek  ---
Like PR92654, started to ICE with r259043.

[Bug c++/92654] [8/9/10 Regression] internal compiler error: in lookup_template_class_1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|internal compiler error: in |[8/9/10 Regression]
   |lookup_template_class_1 |internal compiler error: in
   ||lookup_template_class_1

--- Comment #6 from Jakub Jelinek  ---
The #c0 testcase started to ICE with r259043, before it has been rejected:
pr92654.C: In instantiation of ‘am() [with  =
p]:: [with auto:1 = a::c]’:
pr92654.C:13:4:   required from ‘void ad(ab, a::e) [with ab = am()
[with  = p]::; i = int; i ...ac = {0,
1}]’
pr92654.C:19:4:   required from ‘void k(ab) [with auto j = 2; ab = am() [with
 = p]::]’
pr92654.C:24:12:   required from ‘void ah(ab) [with ag = n; ab = am() [with
 = p]::]’
pr92654.C:32:7:   required from ‘void am() [with  = p]’
pr92654.C:42:18:   required from here
pr92654.C:35:4: error: could not convert template argument ‘b’ from ‘const
a::c’ to ‘n’
if constexpr (o::aq)
^~
pr92654.C: In instantiation of ‘am() [with  =
p]:: [with auto:1 = a::c]’:
pr92654.C:13:4:   required from ‘void ad(ab, a::e) [with ab = am()
[with  = p]::; i = int; i ...ac = {0,
1}]’
pr92654.C:19:4:   required from ‘void k(ab) [with auto j = 2; ab = am() [with
 = p]::]’
pr92654.C:24:12:   required from ‘void ah(ab) [with ag = n; ab = am() [with
 = p]::]’
pr92654.C:32:7:   required from ‘void am() [with  = p]’
pr92654.C:42:18:   required from here
pr92654.C:35:4: error: could not convert template argument ‘b’ from ‘const
a::c’ to ‘n’

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[joel.hutton at arm dot com]

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

--- Comment #6 from Joel Hutton  ---
This should be fixed with Richard Sandifords changes.

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

[jules at gcc dot gnu.org]

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

jules at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jules at gcc dot gnu.org

--- Comment #4 from jules at gcc dot gnu.org ---
SVN r278684 appears to cause a problem with offloading compilation in lto1 with
an nvptx offloading-enabled compiler. The following backtrace is from
libgomp/testsuite/libgomp.fortran/nestedfn5.f90, but many other tests fail
also.

lto1: internal compiler error: in operator[], at vec.h:867
0x894d9a vec::operator[](unsigned int)
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/vec.h:867
0x893924 vec::operator[](unsigned int)
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/vec.h:1433
0x1366f4a streamer_tree_cache_get_tree
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/tree-streamer.h:98
0x136b605 streamer_get_pickled_tree(lto_input_block*, data_in*)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/tree-streamer-in.c:1110
0xde36fc lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto-streamer-in.c:1505
0xde3958 lto_input_tree(lto_input_block*, data_in*)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto-streamer-in.c:1552
0x136a982 lto_input_ts_list_tree_pointers
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/tree-streamer-in.c:863
0x136b4aa streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/tree-streamer-in.c:1075
0xde3303 lto_read_tree_1
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto-streamer-in.c:1375
0xde3480 lto_read_tree
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto-streamer-in.c:1416
0xde389e lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto-streamer-in.c:1528
0xde34fa lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto-streamer-in.c:1440
0x88dd1c lto_read_decls
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto/lto-common.c:1830
0x88ed54 lto_file_finalize
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto/lto-common.c:2227
0x88edae lto_create_files_from_ids
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto/lto-common.c:2237
0x88ef93 lto_file_read
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto/lto-common.c:2292
0x891ee9 read_cgraph_and_symbols(unsigned int, char const**)
   
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto/lto-common.c:2744
0x8698f3 lto_main()
/scratch/jbrown/nvptx-mainline/src/gcc-mainline/gcc/lto/lto.c:630

It looks like something is unprepared to handle a NULL_TREE or error_mark_node
-- I've not finished investigating.

[Bug c++/92582] [10 Regression] internal compiler error: Segmentation fault with concept on constructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-26
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:
template  concept b = requires(a(c)) { c; };
template  struct A {
  template  static constexpr bool d = b;
  template  A(c) requires d;
};
A e { 0 };
With s/concept/concept bool/ and -std=c++17 -fconcepts instead of -std=c++2a
this compiled before r276764 and starting with that revision ICEs.

[Bug lto/92674] [8/9/10 Regression] ICE in gimple_phi_arg, at gimple.h:4406 since r240291

[rguenth at gcc dot gnu.org]

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

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

I am testing the attached.  The testcase seems to be too much reduced to be
useful for the testsuite.

[Bug c++/92662] change in gcc 8 vs 9: call of overloaded ‘basic_string()’ is ambiguous

[matz at gcc dot gnu.org]

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

--- Comment #4 from Michael Matz  ---
Even though bugzilla isn't really for educating people, I'd still like to ask
why the two conversion sequences are deemed either incomparable or equal.  In

  S b { moveme(t) };

the return value of moveme() has type Test&&.  There exists a conversion
operator exactly matching that type, and giving S&&, which can be used for
initialization.  Why is the sequence going via 'const S &' as good as that one,
even though it requires a change in refness?

(In a way it's simply irritating that, despite the same signatures of all
involved functions, the compiler differs between both cases, in particular the
call to str() in 'S a {moveme(t).str()}' also gives type S&&).

[Bug lto/92674] [8/9/10 Regression] ICE in gimple_phi_arg, at gimple.h:4406 since r240291

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Oh, it's not there but

#8  0x011ba073 in expand_call_inline (
bb=, stmt=, 
id=0x7fffd6e0) at /tmp/trunk/gcc/tree-inline.c:5160
5160  gimple_purge_dead_eh_edges (return_block);

does the purging.

[Bug c/92673] OCaml fails to link with recent trunk

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Jürgen Reuter  ---
(In reply to Richard Biener from comment #1)
> Try -fcommon, it's default recently was swapped to -fno-common.

The default for gcc was changed? Which commit was this? I cannot find any
reference in the ChangeLog.