[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #38 from Thomas Koenig  ---
So, I finally have a self-contained test case:

module t2
  implicit none
contains
  subroutine foo(a)
real, dimension(*) :: a
  end subroutine foo
end module t2
module t1
  use t2
  implicit none
contains
  subroutine bar(a)
real, dimension(:) :: a
call foo(a)
  end subroutine bar
end module t1

program main
  use t1
  call bar([1.0, 2.0])
end program main

[Bug c++/70075] incorrect initialization of multidimensional VLAs

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> 
> I get this output on i386-apple-darwin9.8.0 with gcc8:
> 
> $ /usr/local/bin/g++ -Wall -Wextra -Wpedantic -o 70075.exe 70075.cc
> 70075.cc: In function ‘void bar(int)’:
> 70075.cc:4:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
>   char a[m][n] = { { 0, 1, 2 } };
>  ^
> $ ./70075.exe
> 0 1 2 0 0 0 -32 -113 
> $
> 
> (i.e. no errors)

Running the program on x86_64-apple-darwin10.8.0 with gcc9, it prints this
instead:
0 1 2 0 9 0 0 0
(still no errors though)

[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #15 from Eric Gallager  ---
(In reply to Eric Gallager from comment #11)
> (In reply to Manuel López-Ibáñez from comment #9)
> > (In reply to Alex from comment #8)
> > > As to someone implementing clang behavior: I was under the impression that
> > > the attached patch just needed to be applied? That is why I was inquiring 
> > > as
> > > to why nobody had applied it after 3 years.
> > 
> > Writing a patch is often the easy part. The hard part is getting the patch
> > approved and following up on reviewer's comments. See
> > https://gcc.gnu.org/contribute.html and 
> > https://gcc.gnu.org/wiki/GCC_Research
> > 
> > The patch doesn't look correct to me anyway, but you will get a better
> > review from a Darwin maintainer, see the MAINTAINERS file in the gcc 
> > sources.
> 
> Adding them on cc (Only Mike is currently listed as a Darwin maintainer, but
> IMO Iain ought to be listed as one, too)

...and Iain *is* in fact listed as one now, too! I was ahead of the game!

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #37 from Thomas Koenig  ---
Hm, with that patch, there still seems to be a failure in netcdf :-(
I will keep looking (possibly some small problem with the patch).

[Bug c++/70196] inconsistent constness of inequality of weak symbol addresses

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing C++ FE maintainers

[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

--- Comment #6 from Alexander von Gluck  ---
Created attachment 46424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46424=edit
gcc8-verbose.txt

[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

--- Comment #5 from Alexander von Gluck  ---
Created attachment 46423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46423=edit
gcc7-verbose.txt

[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

--- Comment #4 from Alexander von Gluck  ---
ok, this one got kinda long. I've discovered the "how".

gcc7 calling the linker using a --sysroot:

/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/crtn.o


gcc8 calling the linker using a --sysroot:

crtn.o


What would remove the sysroot prefix from the STARTFILES?

[Bug c++/90654] New: GCC doesn't value-initialize base class with trivial default constructor, resulting in uninitialized data

[adrianbibbywalther at gmail dot com]

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

Bug ID: 90654
   Summary: GCC doesn't value-initialize base class with trivial
default constructor, resulting in uninitialized data
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrianbibbywalther at gmail dot com
  Target Milestone: ---

Created attachment 46422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46422=edit
Source code reproducing the bug.

g++ -v produces the following:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=d:/mingw/custom/compilers/gnu/install/bin/../libexec/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../gcc-8.3.0/configure
--prefix=/d/MinGW/Custom/Compilers/gnu/install
--with-gmp=/d/MinGW/Custom/Compilers/gnu/deps-install
--with-mpfr=/d/MinGW/Custom/Compilers/gnu/deps-install
--with-mpc=/d/MinGW/Custom/Compilers/gnu/deps-install
--with-isl=/d/MinGW/Custom/Compilers/gnu/deps-install --disable-nls
--enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-libgomp
--disable-libstdcxx-verbose --disable-win32-registry --enable-threads=posix
--with-sysroot=/d/MinGW/Custom/Compilers/gnu/install --disable-shared
--enable-static CFLAGS='-g0 -O3' 'BOOT_CFLAGS=-g0 -O3' 'CFLAGS_FOR_TARGET=-g0
-O3' CXXFLAGS='-g0 -O3' 'BOOT_CXXFLAGS=-g0 -O3' 'CXXFLAGS_FOR_TARGET=-g0 -O3'
Thread model: posix
gcc version 8.3.0 (GCC)

The command line
g++ -O3 bug.cpp
reproduces the bug in short easy to read, and clearly wrong, assembly. Namely
it reads an uninitialized variable.

-Wall -Wextra reports the variable as uninitialized, which it is, and the bug
is that it shouldn't be. They are a good indication of whether a particular
code sample triggers the bug.

-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fsanitize=undefined have no effect on the output whatsoever.

I have also replicated the bug using the versions of 8.3 and 9.1 on
, so it is not a bug exclusive to MinGW.

It is worth noting it is incredibly fiddle, whether it produces the wrong
assembly or not. The attached code always fails, but slight variations
correctly return 0, although -Wall still reports a warning.

[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

--- Comment #3 from Alexander von Gluck  ---
I ran an strace on it, and it's almost like ld isn't aware of the correct
library directory for our libraries after gcc8...


8838  openat(AT_FDCWD,
"/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/libroot.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/libroot.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/lib/libroot.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/lib/libroot.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/work/generated.ppc/cross-tools-ppc/powerpc-apple-haiku/lib/libroot.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/work/generated.ppc/cross-tools-ppc/powerpc-apple-haiku/lib/libroot.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/local/lib/libroot.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/local/lib/libroot.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/lib/libroot.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/lib/libroot.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/lib/libroot.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  openat(AT_FDCWD,
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/lib/libroot.a",
O_RDONLY) = -1 ENOENT (No such file or directory)
8838  write(2, "/work/generated.ppc/cross-tools-"..., 108) = 108
8838  write(2, ": cannot find ", 14)= 14
8838  write(2, "-lroot", 6) = 6


ld is searching at:
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/usr/lib/libroot.so"

But our libroot.so is at:
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/lib/libroot.so


We didn't touch binutils, so this is all *really* confusing. Did something
change about how gcc calls ld between 7 and 8?

[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

--- Comment #2 from Alexander von Gluck  ---
I was wrong about the autotools aspect... it *is* passing the sysroot to gcc
during the C compiler test.

I reproduced the test configure is running and enabled verbosity...





root@9e90f9304b75:/work/generated.ppc/cross-tools-ppc/bin#
./powerpc-apple-haiku-gcc -O2 -U_FORTIFY_SOURCE
--sysroot=/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc
test.c -v
Using built-in specs.
COLLECT_GCC=./powerpc-apple-haiku-gcc
COLLECT_LTO_WRAPPER=/work/generated.ppc/cross-tools-ppc/libexec/gcc/powerpc-apple-haiku/8.3.0/lto-wrapper
Target: powerpc-apple-haiku
Configured with: /work/src/buildtools/gcc/configure
--prefix=/work/generated.ppc/cross-tools-ppc --target=powerpc-apple-haiku
--disable-nls --disable-shared --with-system-zlib --enable-languages=c,c++
--enable-lto --enable-frame-pointer --enable-__cxa-atexit
--enable-threads=posix --with-default-libstdcxx-abi=gcc4-compatible
--with-sysroot=/work/generated.ppc/cross-tools-ppc/sysroot
--disable-maintainer-mode --disable-multilib --disable-tls
Thread model: posix
gcc version 8.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-O2' '-U' '_FORTIFY_SOURCE' '-v'
 /work/generated.ppc/cross-tools-ppc/libexec/gcc/powerpc-apple-haiku/8.3.0/cc1
-quiet -v -isysroot
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc
-U _FORTIFY_SOURCE test.c -fPIC -Wno-multichar -quiet -dumpbase test.c -auxbase
test -O2 -version -o /tmp/ccIVtwgr.s
GNU C17 (GCC) version 8.3.0 (powerpc-apple-haiku)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/non-packaged/develop/headers/@HYBRID_SECONDARY@"
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/opengl"
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/be_apps/Deskbar"
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/3rdparty"
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/@HYBRID_SECONDARY@"
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/@HYBRID_SECONDARY@/os"
ignoring nonexistent directory
"/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/@HYBRID_SECONDARY@/os/opengl"
#include "..." search starts here:
#include <...> search starts here:
 /work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/include

/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/include-fixed

/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/include

/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os

/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/app

/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/device

/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/drivers

/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/headers/os/game

[Bug c/90653] --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

--- Comment #1 from Alexander von Gluck  ---
Created attachment 46421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46421=edit
config.loh

attached is the config.log from gcc.

I should mention we see the same error across all of our architecture builds
(ppc, x86_64, sparc64, arm, etc)

Notice that the provided with-build-sysroot doesn't seem to be passed to gcc

[Bug c/90653] New: --with-build-sysroot= not honored for ./configure C compiler checks.

[kallisti5 at unixzen dot com]

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

Bug ID: 90653
   Summary: --with-build-sysroot= not honored for ./configure C
compiler checks.
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kallisti5 at unixzen dot com
  Target Milestone: ---

After updating from gcc 7.3.x to 8.3.x, the early stage of our bootstrap is no
longer finding our provided sysroot.

Build flags:
CFLAGS="-O2 -U_FORTIFY_SOURCE" CXXFLAGS="-O2" ./configure \
--build=$buildMachineTriple
--host=$effectiveTargetMachineTriple \
--target=$effectiveTargetMachineTriple --prefix=$installDir \
--libexecdir=$installDir/lib --mandir=$manDir --docdir=$docDir
\
--disable-nls --enable-shared --disable-plugin \
--enable-version-specific-runtime-libs \
--enable-languages=c,c++ --enable-lto --enable-frame-pointer \
--enable-threads=posix --enable-tls \
--with-pkgversion=$(echo $portVersion | cut -c 7-) \
--with-sysroot=/ \
--with-build-sysroot=$sysrootLocation \
--with-threads=posix \
--with-default-libstdcxx-abi=gcc4-compatible \
--disable-libstdcxx-pch \

$sysrootLocation is:
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc


With this, we get:

  "error: C compiler cannot create executables"


Our startfile specs are valid...

#define STANDARD_STARTFILE_PREFIX_1   "/boot/system/non-packaged/develop/lib/"
#define STANDARD_STARTFILE_PREFIX_2   "/boot/system/develop/lib/"


...and we have a valid early build sysroot:

root@9e90f9304b75:/work/generated.ppc# find
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc
| grep develop/lib
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/crti.o
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/crtn.o
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/init_term_dyn.o
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/start_dyn.o
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/haiku_version_glue.o
/work/generated.ppc/objects/haiku/ppc/packaging/repositories/HaikuPortsCross-build/sys-devel/gcc_bootstrap/work-8.3.0_2019_05_24/boot/cross-sysroot/ppc/boot/system/develop/lib/libroot.so


However, we get gcc executed during the configure stage and receive:

/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld:
cannot find crti.o: No such file or directory
/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld:
cannot find start_dyn.o: No such file or directory
/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld:
cannot find init_term_dyn.o: No such file or directory
/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld:
cannot find -lroot
/work/generated.ppc/cross-tools-ppc/lib/gcc/powerpc-apple-haiku/8.3.0/../../../../powerpc-apple-haiku/bin/ld:
cannot find crtn.o: No such file or directory


I'm not sure if this is a autoconf bug, or a gcc bug.  I think *maybe* autoconf
handles the "generate valid executables with C compiler" phase?

[Bug libstdc++/90634] filesystem::path insane memory allocations

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Yes, I'm well aware what the standard says, I reported
https://wg21.link/lwg2674

I consider it a mistake for the standard to say "these are bidirectional
iterators, except they're not, but it's OK because at some point in the future
a subset of algorithms won't care about that requirement any more". GCC's
implementation provides real bidirectional iterators that meet the C++17
requirements and the C++2a BidirectionalIterator requirement that:

"Pointers and references obtained from a forward iterator into a range [i, s)
shall remain valid while [i, s) continues to denote a range."

The libc++ implementation also fails this test:
https://wandbox.org/permlink/RwiFphMn1Hh2iis4
It's OK though, because you don't pay for what you don't use!

The design trade off was discussed in Bug 71044 comment 6. Populating the range
lazily would still be possible (as long as it was thread-safe) but I'm not
convinced it would be an improvement. In theory the range could also be shared
by copies of the same path (again, as long as it was thread-safe). Those
optimizations can be considered later, but for now the implementation aims to
be correct and not produce dangling pointers.

As I said, I'll reduce the number of allocations done by the GCC 8.x
implementation, but I'm not planning on any other changes for now.

[Bug c++/90642] g++ fails to resolve template function overload

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I'm pretty sure this is a dup of an existing bug.

[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Is it possible you're mixing code compiled with GCC 8 and GCC 9? In general
that works, but not for the new C++17 components that were still experimental
in GCC 8, such as filesystem::path.

Valgrind might give you more information about the crash, to help debug the
problem.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #36 from Thomas Koenig  ---
... which should be

Index: testsuite/gfortran.dg/internal_pack_21.f90
===
--- testsuite/gfortran.dg/internal_pack_21.f90  (Revision 271629)
+++ testsuite/gfortran.dg/internal_pack_21.f90  (Arbeitskopie)
@@ -20,5 +20,5 @@
 USE M1
 CALL S2()
 END
-! { dg-final { scan-tree-dump-times "optional" 4 "original" } }
+! { dg-final { scan-tree-dump-times "arg_ptr" 5 "original" } }
 ! { dg-final { scan-tree-dump-not "_gfortran_internal_unpack" "original" } }
ig25@linux-p51k:~/Gcc/trunk/gcc>

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #35 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #34)
> Created attachment 46420 [details]
> Patch which includes a check for being contiguous
> 
> This patch looks like it could do the job.  I'll have to work a bit
> more on test cases and ChangeLog before I can submit this, but
> at least it survives regression testing.

... except for a tree dump scan.  I will look at this later.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #34 from Thomas Koenig  ---
Created attachment 46420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46420=edit
Patch which includes a check for being contiguous

This patch looks like it could do the job.  I'll have to work a bit
more on test cases and ChangeLog before I can submit this, but
at least it survives regression testing.

[Bug tree-optimization/34940] contained subroutines called only once are not inlined

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #14)
> > Note that the IO block escapes and thus cannot be coalesced with others in
> > the same function.  I had a frontend patch to re-use the same IO struct
> > across multiple calls but that was rejected on the grounds of future
> > implementation of async IO.
> 
> I think inline heuristics ignore this fact and just assume overlap across
> sibling calls
> that gets inlined.  Not terribly realistic but not terribly bad either.

Are you still working on this?

[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 27 21:27:00 2019
New Revision: 271671

URL: https://gcc.gnu.org/viewcvs?rev=271671=gcc=rev
Log:
PR libgomp/90641
* work.c (gomp_init_work_share): Instead of aligning final ordered
value to multiples of long long alignment, align to that the
first part (ordered team ids) and if inline_ordered_team_ids
is not on a long long alignment boundary within the structure,
use __alignof__ (long long) - 1 pad size always.
* loop.c (GOMP_loop_start): Fix *mem computation if
inline_ordered_team_ids is not aligned on long long alignment boundary
within the structure.
* loop-ull.c (GOMP_loop_ull_start): Likewise.
* sections.c (GOMP_sections2_start): Likewise.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/loop.c
trunk/libgomp/loop_ull.c
trunk/libgomp/sections.c
trunk/libgomp/work.c

[Bug target/68485] ICE while building gpsd package on microblaze

[giulio.benetti at micronovasrl dot com]

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

--- Comment #8 from Giulio Benetti  ---
This is the build failure log:
http://autobuild.buildroot.net/results/d86/d86251974a0a348a64d9a1d1fd7d02dd4aff0792/build-end.log

[Bug target/68485] ICE while building gpsd package on microblaze

[giulio.benetti at micronovasrl dot com]

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

--- Comment #7 from Giulio Benetti  ---
This Bug still exists on Gcc 9.1.

I have tested it with 4.9/5/6/7/8/9

[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Did libgo ever work on this system?  I can't remember.  I don't see how we can
work around a missing __tls_get_addr symbol.  That suggests that the system
does not support Thread Local Storage.

[Bug target/90639] [10 Regression] Boostrap failure with recent trunk

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Mon May 27 19:12:19 2019
New Revision: 271668

URL: https://gcc.gnu.org/viewcvs?rev=271668=gcc=rev
Log:
rs6000: Fix sanitizer build (PR90639)

The assembler code needs to say it uses AltiVec instructions.


libsanitizer/
PR target/90639
* tsan/tsan_rtl_ppc64.S: Add ".machine altivec".

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/tsan/tsan_rtl_ppc64.S

[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
extern double copysign ();
double foo (double x)
{
  return x * copysign ();
}

ICEs similarly as well, it isn't specific to the _FloatN types (though
copysignf and float instead of copysign and double doesn't, because float isn't
self-promoting and the C FE handles it differently during builtin handling.

That said, I'd say this is a genmatch bug, in that it doesn't do any argument
verification of the builtins, neither in generic nor gimple, and happily uses
CALL_EXPR_ARG (op0, 0) and CALL_EXPR_ARG (op0, 1) or similarly in gimple, when
it didn't even verify the builtin has that many arguments.

[Bug c++/90652] New: Recursive concept leads to segfault

[tobias.bruell at gmail dot com]

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

Bug ID: 90652
   Summary: Recursive concept leads to segfault
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobias.bruell at gmail dot com
  Target Milestone: ---

The following program leads to a seg-fault in gcc. Compile with

-Wall -Wextra -std=gnu++2a "-fconcepts"

It works when using "operator << (os, x)" instead of "os << x" in line 4.

---

#include 

void to_json (std::ostream& os, char c) { os << '"' << c << '"'; }
template concept bool Serializable = requires (T x, std::ostream&
os) { { os << x }; };
template concept bool ToJson = requires (T x, std::ostream& os) { {
to_json (os, x) }; };

template
  requires ToJson && !Serializable
std::ostream& operator << (std::ostream& os, T const& x)
{
  to_json (os, x);
  return os;
}

int main ()
{
  static_assert (Serializable);
  static_assert (ToJson);

  std::cout << 'c';
}

[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Both started with r256026.  I'll have a look.

[Bug d/90651] New: ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524

[gs...@t-online.de]

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

Bug ID: 90651
   Summary: ICE in FuncDeclaration::semantic3, at
d/dmd/func.c:1524
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

$ cat z1.d
struct object {}
void f (...) {}
int g (object a);


$ gdc-10-20190526 -c z1.d
d21: internal compiler error: Segmentation fault
0xb7057f crash_signal
../../gcc/toplev.c:326
0x6cb025 FuncDeclaration::semantic3(Scope*)
../../gcc/d/dmd/func.c:1524
0x66c57f Module::semantic3(Scope*)
../../gcc/d/dmd/dmodule.c:814
0x766905 d_parse_file()
../../gcc/d/d-lang.cc:1201

[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Target||x86_64-pc-linux-gnu

--- Comment #1 from G. Steinmetz  ---

And nearby testcase ...


$ cat z2.d
class c
{
  static f ()
  {
return 0;
  }
}
void g ()
{
  if ([0] & c.f()) {}
}


$ gdc-10-20190526 -c z2.d
z2.d: In function 'g':
z2.d:10:7: internal compiler error: tree check: expected none of record_type or
union_type or qual_union_type or array_type, have record_type in
fold_binary_loc, at fold-const.c:9782
   10 |   if ([0] & c.f()) {}
  |   ^
0x608666 tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9939
0x9a4f4e tree_not_check4(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code)
../../gcc/tree.h:3262
0x982c4e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9782
0x98bbaa fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x79c7f7 ExprVisitor::binary_op(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/d/expr.cc:165
0x79c7f7 ExprVisitor::visit(BinExp*)
../../gcc/d/expr.cc:674
0x79bc7f build_expr(Expression*, bool)
../../gcc/d/expr.cc:3076
0x79bd59 build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3099
0x7acacf IRVisitor::visit(IfStatement*)
../../gcc/d/toir.cc:554
0x7abe92 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x7abe92 IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1042
0x7ab821 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x7ab821 build_function_body(FuncDeclaration*)
../../gcc/d/toir.cc:1447
0x79a844 DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:1006
0x794a16 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x7a9640 build_module_tree(Module*)
../../gcc/d/modules.cc:726
0x799a3b DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:147
0x794a16 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x792c57 d_parse_file()
../../gcc/d/d-lang.cc:1310

[Bug d/90650] New: ICE in fold_convert_loc, at fold-const.c:2552

[gs...@t-online.de]

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

Bug ID: 90650
   Summary: ICE in fold_convert_loc, at fold-const.c:2552
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With snapshot from 20190526 :


$ cat z1.d
class c
{
  static f ()
  {
return 0;
  }
}
void g ()
{
  if (0 & [0] & c.f()) {}
}


$ gdc-10-20190526 -c z1.d
z1.d: In function 'g':
z1.d:10:15: internal compiler error: in fold_convert_loc, at fold-const.c:2552
   10 |   if (0 & [0] & c.f()) {}
  |   ^
0x8f27b3 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2552
0x8ebaf8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9437
0x8f06ca fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x76d7fb ExprVisitor::binary_op(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/d/expr.cc:165
0x76d7fb ExprVisitor::visit(BinExp*)
../../gcc/d/expr.cc:674
0x76ce3e build_expr(Expression*, bool)
../../gcc/d/expr.cc:3076
0x76ced9 build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3099
0x77949f IRVisitor::visit(IfStatement*)
../../gcc/d/toir.cc:554
0x778a22 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x778a22 IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1042
0x778561 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x778561 build_function_body(FuncDeclaration*)
../../gcc/d/toir.cc:1447
0x76c0e4 DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:1006
0x769026 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x7768b0 build_module_tree(Module*)
../../gcc/d/modules.cc:726
0x76b4ab DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:147
0x769026 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x767214 d_parse_file()
../../gcc/d/d-lang.cc:1310

[Bug c/90649] New: ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857

[gs...@t-online.de]

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

Bug ID: 90649
   Summary: ICE tree check: accessed operand 4 of call_expr with 3
operands in generic_simplify_EQ_EXPR, at
generic-match.c:42857
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gcc-5 :
(release versions need -Ofast)


$ cat z1.c
double sqrt ();
void f ()
{
  !sqrt ();
}


$ gcc-10-20190526 -c z1.c -Ofast
z1.c: In function 'f':
z1.c:4:4: warning: too few arguments to built-in function 'sqrt' expecting 1
[-Wbuiltin-declaration-mismatch]
4 |   !sqrt ();
  |^~~~
z1.c:1:8: note: declared here
1 | double sqrt ();
  |^~~~
z1.c:4:3: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
4 |   !sqrt ();
  |   ^
0x5bd990 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/tree.c:10116
0x64cbb1 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3685
0x118c201 generic_simplify_EQ_EXPR
.../gcc/generic-match.c:42857
0x11da03d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.../gcc/generic-match.c:53417
0x8d49dd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9387
0x8ddeba fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x6833a9 c_fully_fold_internal
../../gcc/c/c-fold.c:370
0x6850a7 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x61f6d1 c_process_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11058
0x61fabd c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11103
0x673898 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5611
0x6757ce c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5149
0x675f56 c_parser_compound_statement
../../gcc/c/c-parser.c:4983
0x677873 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2355
0x67fea3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x680969 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x680969 c_parse_file()
../../gcc/c/c-parser.c:19884
0x6e26d0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug c/90648] New: [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222

[gs...@t-online.de]

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

Bug ID: 90648
   Summary: [8/9/10 Regression] ICE tree check: accessed operand 4
of call_expr with 3 operands in
generic_simplify_MULT_EXPR, at generic-match.c:27222
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8, compiles with gcc-7 :


$ cat z1.c
extern _Float128 copysignf128 ();
_Float128 foo (_Float128 x)
{
  return x * copysignf128 ();
}


$ cat z2.c
extern _Float128 copysignf128 (x);
double foo (double x)
{
  return x * copysignf128 ();
}


$ gcc-7 -c z1.c
$
$ gcc-10-20190526 -c z1.c
z1.c: In function 'foo':
z1.c:4:14: warning: too few arguments to built-in function 'copysignf128'
expecting 2 [-Wbuiltin-declaration-mismatch]
4 |   return x * copysignf128 ();
  |  ^~~~
z1.c:1:18: note: declared here
1 | extern _Float128 copysignf128 ();
  |  ^~~~
z1.c:4:3: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
4 |   return x * copysignf128 ();
  |   ^~
0x5bd990 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/tree.c:10116
0x64cbb1 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3685
0x116a717 generic_simplify_MULT_EXPR
.../gcc/generic-match.c:27222
0x11da8fd generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.../gcc/generic-match.c:53387
0x8d49dd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9387
0x8ddeba fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x8d4c1d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9379
0x8f6ef4 fold(tree_node*)
../../gcc/fold-const.c:11949
0x683cca c_fully_fold_internal
../../gcc/c/c-fold.c:373
0x6850a7 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x629175 c_finish_return(unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:10523
0x673c3a c_parser_statement_after_labels
../../gcc/c/c-parser.c:5524
0x6757ce c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5149
0x675f56 c_parser_compound_statement
../../gcc/c/c-parser.c:4983
0x677873 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2355
0x67fea3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x680969 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x680969 c_parse_file()
../../gcc/c/c-parser.c:19884
0x6e26d0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
So mark as a dup of bug 44715.

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

[Bug c/44715] Break in increment expression of "for" statement inconsistent with g++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bastian.beischer@rwth-aache
   ||n.de

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

[Bug c++/90647] New: Warn on returning a lambda with captured local variables

[antoshkka at gmail dot com]

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

Bug ID: 90647
   Summary: Warn on returning a lambda with captured local
variables
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

auto test(int s) {
return [] { return s; };
}


`s` is a local variable, so we return a lambda that has a dangling reference.

It would be nice to have a warning for such cases.

[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
See PR44715 and
https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b

[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults

[myLC at gmx dot net]

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

myLC at gmx dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from myLC at gmx dot net ---
The example works with the same path. The real code is correct, though.
I'm guessing this might have something to do with a 3rd-party library
corrupting memory, The library needs to be built with the same compiler and
options (Nana C++).
I need to rebuild that thing and see, if this fixes it.
I apologize. I should have created an example first.

[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults

[myLC at gmx dot net]

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

--- Comment #3 from myLC at gmx dot net ---
(In reply to Andrew Pinski from comment #2)
> Can you provide a compilable example?

Good point. The example works, hence the problem seems to be somewhere else:

#include 
#include 
#include 
#include 

std::optional< std::string > read( const std::filesystem::path , const
std::string  ) {
std::string s;
if( !filename.empty() ) {
std::filesystem::path file( path );
file /= filename;
if( std::filesystem::exists( file ) ) {
std::ifstream input( std::filesystem::absolute( file )
);
std::stringstream buffer;
buffer << input.rdbuf();
if( input.bad() )
goto errout;
s = buffer.str();
}
} else {
errout: return {};
}
return s;
}

int main( int argc, char **argv ) {
std::string read_write_test;
if( auto rwt = read( "./", argv[ 0 ] ) )
read_write_test = *rwt;
if( !read_write_test.empty() )
  std::cout << "fine" << std::endl;
return 0;
}

I need to investigate this further...

[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #2 from Andrew Pinski  ---
Can you provide a compilable example?

[Bug c++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults

[myLC at gmx dot net]

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

--- Comment #1 from myLC at gmx dot net ---
Forgot to mention that it's C++20 (-std=c++2a).

[Bug c++/90646] New: std::filesystem::absolute( "yourpathhere" ) segfaults

[myLC at gmx dot net]

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

Bug ID: 90646
   Summary: std::filesystem::absolute( "yourpathhere" ) segfaults
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myLC at gmx dot net
  Target Milestone: ---

This used to work with g++-8.1.0, but segfaults with g++-9.1.0:

std::optional< std::string > Config::read( const std::filesystem::path ,
const std::string  ) {
std::string s;
if( !filename.empty() ) {
std::filesystem::path file( path );
file /= filename;
if( std::filesystem::exists( file ) ) {
std::ifstream input( std::filesystem::absolute( file )
);
std::stringstream buffer;
buffer << input.rdbuf();
if( input.bad() )
goto errout;
s = buffer.str();
}
} else {
errout: return {};
}
return s;
}

Now it crashes at calling "std::filesystem::absolute( file )":
Thread 1 "config_module" received signal SIGSEGV, Segmentation fault.
0x00462b2f in std::unique_ptr::~unique_ptr (
this=0xb, __in_chrg=) at
/usr/include/c++/9/bits/unique_ptr.h:288
288 if (__ptr != nullptr)

(gdb) p __ptr
$1 = (std::filesystem::path::_List::_Impl *&) @0x7fffd1d8: 0x0
(gdb)

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[bogi788 at hotmail dot com]

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

--- Comment #11 from bogi788 at hotmail dot com ---
(In reply to Martin Liška from comment #6)
> Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from
> source files?

I tried again in a new rhel7 vm, going straight from distibution gcc (4.8.5) to
9.1 rather than upgrading from gcc 8.3. That resulted in a gcc 9.1 that didn't
cause an internal compiler error, but since I used the 3 stage build in both
cases I'm not sure how that might have caused the problem.

[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'

[mfe at live dot de]

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

--- Comment #2 from martin  ---
Created attachment 46419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46419=edit
usr\include\bits

ldd --version  
   
  ldd (GNU libc) 2.3.2 
   
  Copyright (C) 2003 Free Software Foundation, Inc.
   
  This is free software; see the source
for copying conditions.  There is NO   
  warranty; not
even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  
   
  Written by Roland McGrath and Ulrich Drepper.

[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>fdopendir() is available in glibc since version 2.4.

What glibc version are you using?

[Bug go/90645] New: sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'

[mfe at live dot de]

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

Bug ID: 90645
   Summary: sparc-unknown-linux-gnu/libgo/.libs/libgo.so:
undefined reference to `fdopendir'
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mfe at live dot de
CC: cmang at google dot com
  Target Milestone: ---

the exact version of GCC:
gcc-9.1.0

the system type:
NetgearReadyNAS Duo
(http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS)

the options given when GCC was configured/built:
../gcc-9.1.0/configure CC=/opt/gcc-7.1/bin/gcc CXX=/opt/gcc-7.1/bin/g++
--enable-languages=c,c++,go --prefix=/opt/gcc-9.1 --with-cpu=v7
--with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local
--with-isl=/usr/local/ --disable-libstdcxx-pch --disable-linux-futex
--disable-libsanitizer --enable-__cxa_atexit --enable-nls --enable-clocale=gnu
--enable-debug --disable-doc --disable-libcilkrts --disable-libitm


the complete command line that triggers the bug;
/usr/local/bin/make

the compiler output (error messages, warnings, etc.);
[...]
make[2]: Entering directory
'/c/backup/fes-readynasduo/gcc-9.1.0-compiled/gotools'
/backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/gccgo
-B/backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/
-B/opt/gcc-9.1/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-9.1/sparc-unknown-linux-gnu/lib/ -isystem
/opt/gcc-9.1/sparc-unknown-linux-gnu/include -isystem
/opt/gcc-9.1/sparc-unknown-linux-gnu/sys-include   -g -O2 -I
../sparc-unknown-linux-gnu/libgo -static-libstdc++ -static-libgcc  -L
../sparc-unknown-linux-gnu/libgo -L ../sparc-unknown-linux-gnu/libgo/.libs -o
go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/alldocs.go
../../gcc-9.1.0/gotools/../libgo/go/cmd/go/go11.go
../../gcc-9.1.0/gotools/../libgo/go/cmd/go/main.go
../sparc-unknown-linux-gnu/libgo/libgotool.a
../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to
`fdopendir'
../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to
`__sync_bool_compare_and_swap_4'
../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to
`__tls_get_addr'
../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to
`__go_openat'
../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to
`fstatat64'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:821: go] Error 1
make[2]: Leaving directory
'/c/backup/fes-readynasduo/gcc-9.1.0-compiled/gotools'
make[1]: *** [Makefile:15520: all-gotools] Error 2
make[1]: Leaving directory '/c/backup/fes-readynasduo/gcc-9.1.0-compiled'
make: *** [Makefile:993: all] Error 2

 ldd -r /backup/fes-readynasduo/gcc-9.1.0-compiled/gcc/gccgo   
   
  libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x2002c000)   
   
  libm.so.6 => /lib/libm.so.6 (0x20124000) 
   
  libc.so.6 => /lib/libc.so.6
(0x201b8000)   
   
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000)

/backup/fes-readynasduo/gcc-9.1.0-compiled/gcc/gccgo --version 
   
  gccgo (GCC) 9.1.0
   
  Copyright (C) 2019 Free Software Foundation, Inc.
   
  This is free software; see the source
for copying conditions.  There is NO   
  warranty; not
even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

Not sure which information is important for this bug.

[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)

[mfe at live dot de]

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

--- Comment #7 from martin  ---
(In reply to Ian Lance Taylor from comment #6)
> Fixed on trunk and GCC 9 branch.

Many thanks!

[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Jakub Jelinek  ---
> Created attachment 46418
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46418=edit
> gcc10-pr90641.patch
>
> Untested fix.

Worked for me: I've rebuilt libgomp with the patch and ran the two
affected tests (as C and C++) for 32 and 64-bit.  All PASS now.

Thanks.
Rainer

[Bug tree-optimization/88440] size optimization of memcpy-like code

[clyon at gcc dot gnu.org]

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

--- Comment #26 from Christophe Lyon  ---
Author: clyon
Date: Mon May 27 13:37:57 2019
New Revision: 271662

URL: https://gcc.gnu.org/viewcvs?rev=271662=gcc=rev
Log:
[testsuite,aarch64,arm] PR88440: Fix testcases

2019-05-27  Christophe Lyon  

PR tree-optimization/88440
gcc/testsuite/
* gcc.target/aarch64/sve/index_offset_1.c: Add
-fno-tree-loop-distribute-patterns.
* gcc.target/aarch64/sve/single_1.c: Likewise.
* gcc.target/aarch64/sve/single_2.c: Likewise.
* gcc.target/aarch64/sve/single_3.c: Likewise.
* gcc.target/aarch64/sve/single_4.c: Likewise.
* gcc.target/aarch64/sve/vec_init_1.c: Likewise.
* gcc.target/aarch64/vect-fmovd-zero.c: Likewise.
* gcc.target/aarch64/vect-fmovf-zero.c: Likewise.
* gcc.target/arm/ivopts.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/sve/index_offset_1.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/single_1.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/single_2.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/single_3.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/single_4.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/vec_init_1.c
trunk/gcc/testsuite/gcc.target/aarch64/vect-fmovd-zero.c
trunk/gcc/testsuite/gcc.target/aarch64/vect-fmovf-zero.c
trunk/gcc/testsuite/gcc.target/arm/ivopts.c

[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

[Igor.Smirnov at cern dot ch]

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

--- Comment #8 from Igor Smirnov  ---
Let me add corrections to my previous post.
1. It needs to add (long double) before M_PI / LONG_MAX in the line
long double phid = M_PI / LONG_MAX; 
in the above example. But the result is not changed significantly.
2. Two results for the very last expression for C++ and C++17 are correct.
3. In the other expressions only the versions 4.8.5, C++03 and C++03(GNU) give
completely wrong results. Do you support "C++03"? The other versions give the
correct real component and the imaginary component with wrong sign, but since
this component is anyway extremely small, this can be explained by precision
problems.

[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46418=edit
gcc10-pr90641.patch

Untested fix.

[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon May 27 13:18:12 2019
New Revision: 271661

URL: https://gcc.gnu.org/viewcvs?rev=271661=gcc=rev
Log:
2019-05-27  Richard Biener  

PR tree-optimization/90637
* tree-ssa-sink.c (statement_sink_location): Honor the
computed sink location for single-uses.

* gcc.dg/gomp/pr90637.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr90637.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sink.c

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[bogi788 at hotmail dot com]

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

--- Comment #10 from bogi788 at hotmail dot com ---
(In reply to bogi788 from comment #8)
> (In reply to Martin Liška from comment #6)
> > Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from
> > source files?
> 
> This was on gcc 9.1 compiled from source on rhel7. I can't provide a docker
> image, but I can try compiling gcc on an Arch Linux box.

gcc 9.1.0 built from the same sources (using the same flags) on arch linux
instead of rhel7 compiles the .c file without internal compiler error.

[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

[Igor.Smirnov at cern dot ch]

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

--- Comment #7 from Igor Smirnov  ---
There can be still problems with big integer powers of complex numbers in the
latest versions.
I just don't see a single correct answer.
As above the expected correct responses are marked by "should be" and the
received by "actually".
Notations of version started from "C++" are from the above mentioned site:

---


#include 
#include 
#include 

int main(void)
{
  double phi = M_PI / LONG_MAX;
  std::cout< var0 = std::polar(1.0, phi);
  std::cout< vard0 = std::polar((long double)1.0, phid);
  std::cout< var1 = std::polar(1.0, phi1);
  std::cout<

[Bug tree-optimization/90644] Call to __builtin_memcmp not folded for identical vectors

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/90644] Call to __builtin_memcmp not folded for identical vectors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-27
  Component|target  |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think we simply miss folding __builtin_memcmp_eq (, , CST) to
x != y for compatible register types x/y and CST equal to the registers size.
Of course only for integral typed registers (we might be able to use
VIEW_CONVERT_EXPR to convert to an integer [vector] we can compare though).

I think there's a related bug to "inline" memcmp_eq if it can be performed
with a single register compare (similar to how we inline memcpy).  I
thought we already do this (but IIRC only for size == 1).  Might be we
only do this during RTL expansion.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #33 from Martin Liška  ---
(In reply to Thomas Koenig from comment #32)
> Hi Martin,
> 
> this
> 
> 3822   ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))
> 
> looks like the culprit (or rather, where gfortran currently
> generates wrong code).  This is consistent with the problem seen
> in netcdf, so I feel pretty confident that this is indeed the problem.
> 
> To double-check, could you maybe do the following? Assume ps0 is a
> real(kind=8) variable, do
> 
> ...
> 
>real(kind=8) :: ps0_array(1) ! Use the type as ps0
> 
> and then
> 
> ps0_array(1) = ps0
> ierr = pio_put_var (tape(t)%File, ps0var, ps0_array)
> 
> and see if the segfault goes away, or at least if this one has
> been removed, and there is a different one now :-)

Yes, I can confirm it helps. I see a segfault later then.
Thank you.

[Bug tree-optimization/90594] [9/10 regression] Spurious popcount emitted

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Created attachment 46417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46417=edit
prerequesite

This is the prerequesite for getting rid of the seprate pass doing final value
replacement.  It makes DCE elide LC PHI nodes if there's a DEF to eliminate.

Note the patch isn't 100% finished because it doesn't yet deal with the
undefined overflow issue (easy to add) and I've left out cost considerations
(also to incerase coverage for testing).  The factoring is also not actually
factoring (well, if the pass vanishes...).

As followup we'd remove the SCEV cprop pass.

There are still other passes that could consider doing final value replacement
more aggressively of course (unvectorizable/parallelizable reductions,
IVOPTs, etc.).  So the chance is that with the DCE approach mainly aiming
at pattern detection and loop removal we'd regress elsewhere.

I've looked at mitigating the bad decision done for the testcase in this
bug in the final value replacement pass itself but doing so doesn't look
possible w/o replicating DCE.

[Bug tree-optimization/90594] [9/10 regression] Spurious popcount emitted

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #32 from Thomas Koenig  ---
Hi Martin,

this

3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))

looks like the culprit (or rather, where gfortran currently
generates wrong code).  This is consistent with the problem seen
in netcdf, so I feel pretty confident that this is indeed the problem.

To double-check, could you maybe do the following? Assume ps0 is a
real(kind=8) variable, do

...

   real(kind=8) :: ps0_array(1) ! Use the type as ps0

and then

ps0_array(1) = ps0
ierr = pio_put_var (tape(t)%File, ps0var, ps0_array)

and see if the segfault goes away, or at least if this one has
been removed, and there is a different one now :-)

[Bug target/90644] New: Call to __builtin_memcmp not folded for identical vectors

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 90644
   Summary: Call to __builtin_memcmp not folded for identical
vectors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For following test-case:

#include 

typedef int32_t vnx4si __attribute__((vector_size (32)));

void foo(int a, int b)
{
  vnx4si v = (vnx4si) { a, b, 1, 2 };
  vnx4si expected = (vnx4si) { a, b, 1, 2 };

  if (__builtin_memcmp (, , sizeof (vnx4si)) != 0)
__builtin_abort ();
}

-O2 -ftree-vectorize -march=armv8.2-a+sve folds call to __builtin_memcmp
correctly, since both vectors are identical.

But with -msve-vector-bits=256, it fails to fold the call to
__builtin_memcmp().

The issue can also be reproduced with AdvSIMD: Fails to fold the call to
__builtin_memcmp with vector_size == 16 but folds with vector_size == 32.

Thanks,
Prathamesh

[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

[Igor.Smirnov at cern dot ch]

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

--- Comment #6 from Igor Smirnov  ---
Mark, thank you for useful advice.

So, my conclusion is that the rules for resolution in the presence of 
function templates are not changed in gcc. For all versions of C++ 
the result generated by this site was the same. The program is compiled without 
"call ... is ambiguous" complaints, and calls the variant of the function 
for "int" argument when called with long double: 

fun(1.1, 1)=
fun(T,  int) is working.
1.1
fun(1.1, 1/2.0)=
fun(T, const T&) is working.
0.55
fun(1.1, (long double)1/2.0)=
fun(T,  int) is working.
0

This behaviour is counter to logic because an identical program with 
with almost identical ordinary functions is NOT compiled with complaint
"prog.cc:21:28: error: call of overloaded 'fun(double, double)' is ambiguous",
see an example below.
Since the user may not even know that the functions are template
(an ordinary function can depend on agruments having a fully specified 
template type), he may not notice this error. 



#include 

double fun(double x, int i)
{
  std::cout<<"fun(double,  int) is working.\n";
  return x * i;
}

double fun(double x, const long double& d)
{
  std::cout<<"fun(double, const long double&) is working.\n";
  return x * d;
}

int main(void)
{
  std::cout<<"fun(1.1, 1)="<<'\n';
  

[Bug c++/90643] Code works with differences on ICC and GNU++

[karaul0v at yandex dot ru]

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

Monster  changed:

   What|Removed |Added

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

--- Comment #1 from Monster  ---
Users complain that in GNU ++ very strange incredible errors appear in the
game. Which are not in the ICC compilers.

How to find code that can work in ICC with other result than in GNU ++?
(undefined behaviour?)

Any static analyzer can found this problems?

[Bug c++/90643] New: Code works with differences on ICC and GNU++

[karaul0v at yandex dot ru]

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

Bug ID: 90643
   Summary: Code works with differences on ICC and GNU++
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karaul0v at yandex dot ru
  Target Milestone: ---

Users complain that in GNU ++ very strange incredible errors appear in the
game. Which are not in the ICC compilers.

How to find code that can work in ICC with other result than in GNU ++?
(undefined behaviour?)

Any static analyzer can found this problems?

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
(In reply to bogi788 from comment #8)
> (In reply to Martin Liška from comment #6)
> > Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from
> > source files?
> 
> This was on gcc 9.1 compiled from source on rhel7. I can't provide a docker
> image, but I can try compiling gcc on an Arch Linux box.

@Jakub: Can you please reproduce that?

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[bogi788 at hotmail dot com]

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

--- Comment #8 from bogi788 at hotmail dot com ---
(In reply to Martin Liška from comment #6)
> Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from
> source files?

This was on gcc 9.1 compiled from source on rhel7. I can't provide a docker
image, but I can try compiling gcc on an Arch Linux box.

[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Jakub Jelinek  ---
> Does malloc guarantee sufficient alignment for long long?

It does: 8 bytes for 32-bit, 16 bytes for 64-bit with the libc malloc.

> What is offsetof (struct gomp_work_share, inline_ordered_team_ids) on the
> target?

ptype/o shows

/*  140  | 0 */unsigned int inline_ordered_team_ids[0];
/* XXX 52-byte padding */

[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Mon May 27 10:52:14 2019
New Revision: 271652

URL: https://gcc.gnu.org/viewcvs?rev=271652=gcc=rev
Log:
2019-05-27  Richard Biener  

PR middle-end/90610
* match.pd (vec_perm): Avoid clobbering op0 when not generating
a bit-insert.

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org]

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

Bug 90610 Summary: [10 Regression] 526.blender_r miscompared on znver1 with 
-Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610

   What|Removed |Added

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

[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
Igor, there are free websites that let you check it for yourself very easily,
for instance https://wandbox.org/ , you can test many versions of the compiler
online there.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #31 from Martin Liška  ---
I see this:

(gdb) frame
#2  0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=...,
vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468
2468ierr = put_var_1d_double (File, vardesc%varid, ival)
(gdb) up
#3  0x005be633 in cam_history::h_define (restart=4294949912, t=-17380)
at cam_history.fppized.f90:3822
3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/))
(gdb) up
#4  cam_history::wshist (rgnht_in=) at cam_history.fppized.f90:4461
4461  call h_define (t, restart)
(gdb) up
#5  0x007811dc in cam_comp::cam_run4 (cam_out=..., cam_in=...,
rstwr=.FALSE., nlend=.FALSE., yr_spec=0, mon_spec=1, day_spec=1, sec_spec=1800)
at cam_comp.fppized.f90:325
325call wshist ()
(gdb) up
#6  0x0079d809 in atm_comp_mct::atm_run_mct (eclock=..., cdata_a=...,
x2a_a=..., a2x_a=...) at atm_comp_mct.fppized.f90:513
513 yr_spec=yr_sync, mon_spec=mon_sync, day_spec=day_sync,
sec_spec=tod_sync)
(gdb) up
#7  0x007deb03 in ccsm_comp_mod::ccsm_run () at
ccsm_comp_mod.fppized.f90:2408
2408 call atm_run_mct( EClock_a, cdata_aa, x2a_aa, a2x_aa)
(gdb) up
#8  0x00403772 in ccsm_driver () at ccsm_driver.fppized.f90:58
58 call ccsm_run()
(gdb) up
#9  main (argc=argc@entry=1, argv=0x7fffdffe) at ccsm_driver.fppized.f90:25
25 use shr_sys_mod,   only: shr_sys_abort
(gdb) up
#10 0x779b6b7b in __libc_start_main (main=0x403740 , argc=1,
argv=0x7fffdb98, init=, fini=,
rtld_fini=, stack_end=0x7fffdb88) at ../csu/libc-start.c:308
308   result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
(gdb) up
#11 0x004037ba in _start () at ../sysdeps/x86_64/start.S:120
120 ../sysdeps/x86_64/start.S: No such file or directory.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #30 from Thomas Koenig  ---
Hi,

what I mean is if you use "up" several times and list the
source of the calling routines, do you encounter something like

  call foo([1.0, 2.0, 3.0, 4.0])

or

  call foo((/1.0, 2.0, 3.0, 4.0/))

?

This is what I see for netcdf, and then I can also understand what
goes wrong. Such an array constructor would be in read-only memory,
and the current version would try to write back to it on exit -
ouch :-)

[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
OK, so sinking computes the correct block to sink to in

  sinkbb = gimple_bb (use);
  sinkbb = select_best_block (frombb, gimple_bb (use), stmt);

  if (sinkbb == frombb)
return false;

  *togsi = gsi_for_stmt (use);

but then picks 'use' for togsi even though that is in a different block...

The following fixes it:

Index: gcc/tree-ssa-sink.c
===
--- gcc/tree-ssa-sink.c (revision 271644)
+++ gcc/tree-ssa-sink.c (working copy)
@@ -439,7 +439,10 @@ statement_sink_location (gimple *stmt, b
  if (sinkbb == frombb)
return false;

- *togsi = gsi_for_stmt (use);
+ if (sinkbb == gimple_bb (use))
+   *togsi = gsi_for_stmt (use);
+ else
+   *togsi = gsi_after_labels (sinkbb);

  return true;
}

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Or you can provide a docker image that will show that?

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from
source files?

[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

[Igor.Smirnov at cern dot ch]

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

--- Comment #4 from Igor Smirnov  ---
Richard, thanks for checks. 
Yes this is correct result.
I am wondering, do they correct this problem for complex<> and for inbuilt
types only? 
Is there a possibility for you to run the following program on these new
versions and to show the results:



#include 

template< class T>
double fun(const T& x, int i)
{
  std::cout<<"fun(const T&,  int) is working.\n";
  return x * i;
}


template< class T>
double fun(const T& x, const T& d)
{
  std::cout<<"fun(const T&, const T&) is working.\n";
  return x * d;
}

int main(void)
{
  std::cout<<"fun(1.1, 1)="<<'\n';
  

[Bug libstdc++/90634] filesystem::path insane memory allocations

[1000hz.radiowave at gmail dot com]

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

--- Comment #7 from baltic <1000hz.radiowave at gmail dot com> ---
(In reply to Jonathan Wakely from comment #5)

> So don't store them as filesystem::path objects then, store them as strings
> and create a path as needed.

Type system is here for a reason. And it has advantages to type something,
which is naturally a path, as such, not as an arbitrary string.

> GCC's implementation creates the path components eagerly, so that
> path::iterator meets the requirements of a forward iterator, whereas the
> libc++ implementation creates them lazily during iteration, and so is not a
> valid forward iterator. 

It doesn't have to be. See standard 30.11.7.5:

A path::iterator is a constant iterator satisfying all the requirements of a
bidirectional iterator (27.2.6)
except that, for dereferenceable iterators a and b of type path::iterator with
a == b, there is no requirement
that *a and *b are bound to the same object. Its value_type is path.

> The implementations have different trade-offs. That is not a bug.

Poorly considered trade-offs are called "bad design" ;)
Besides, your implementation breaks the fundamental C++ design principle "you
don't pay for what you don't use". now everyone has to pay x10 memory overhead
even if they are not ever going to iterate over a path object. I agree, that is
not a bug, in C++ world, its a pure crime ;)

[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Cleaned up testcase.

/* PR tree-optimization/90637 */
/* { dg-do compile } */
/* { dg-options "-fopenmp -O1 --param sink-frequency-threshold=90" } */

int v;

void
foo (int c)
{
  int i;
#pragma omp for simd if (c) lastprivate (v) schedule (static, 16)
  for (i = 0; i < 64; ++i)
v = i;
}

This is something where I had initially punting rather than assert.
I must say what the sinking pass is doing looks very bad, mainly the sinking of
the omp_get_num_threads () from before the outer loop to inside of the outer
loop (but not inner loop), how that can ever be an advantage, instead of
calling it just once, call it several times?
For the reason of the ICE, sinking of the _1 = c_22(D) != 0, perhaps we could
add a hack/workaround to the sink pass not to sink with flag_openmp{,_simd} if
an immediate use is the .GOMP_SIMD_LANE call, or we could try to hoist it out
of the loop again (which wouldn't work if sinking sinks more than one statement
dependent on each other into the loop).

[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Testing

Index: gcc/match.pd
===
--- gcc/match.pd(revision 271644)
+++ gcc/match.pd(working copy)
@@ -5453,8 +5453,8 @@ (define_operator_list COND_TERNARY
   first vector we only can insert the first elt from
   the first vector.  */
at = 0;
-   ins = fold_read_from_vector (cop0, 0);
-   op0 = op1;
+   if ((ins = fold_read_from_vector (cop0, 0)))
+ op0 = op1;
  }
else
  {

[Bug c++/90642] New: g++ fails to resolve template function overload

[oknenavin at outlook dot com]

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

Bug ID: 90642
   Summary: g++ fails to resolve template function overload
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oknenavin at outlook dot com
  Target Milestone: ---

the following code fails to compile:

template 
inline void func(const T&, R...) {}

template 
struct S {};

template 
inline void func(const S&, R...) {}

int main() {
func(42);
func(S()); // OK
func(S(), 1); // NOK
func(S(), 1); // NOK
}

with:

: In function 'int main()':
:13:21: error: call of overloaded 'func(S, int)' is ambiguous
 func(S(), 1); // NOK
 ^
:13:21: note: candidates are:
:2:17: note: void func(const T&, R ...) [with X = int; T = S;
R = {int}]
 inline void func(const T&, R...) {}
 ^
:8:17: note: void func(const S&, R ...) [with X = int; T = int;
R = {int}]
 inline void func(const S&, R...) {}
 ^
:14:26: error: call of overloaded 'func(S, int)' is ambiguous
 func(S(), 1); // NOK
  ^
...

Reproducible with 4.8.1 and 9.1. Compiles with clang (v3.0.0 and v8.0.0), icc
(v13.0.1 and v19.0.1), msvc (v19.14 and v19.20).

[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Does malloc guarantee sufficient alignment for long long?
What is offsetof (struct gomp_work_share, inline_ordered_team_ids) on the
target?

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[bogi788 at hotmail dot com]

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

--- Comment #5 from bogi788 at hotmail dot com ---
(In reply to Martin Liška from comment #4)
> (In reply to bogi788 from comment #2)
> > Created attachment 46414 [details]
> > gcc 8.3.0 preprocessed source
> > 
> > The .i file was generated using gcc 8.3.0, since (as mentioned in the
> > bugreport) gcc 9.1.0 writes an almost empty file.
> 
> Do you see the ICE if you use 8.3.0 generated file? Can you please provide
> output of --verbose?

gcc 8.3.0 compiles the source file without error, but gcc 9.1.0 still results
in the internal compiler error using gcc 8.3.0's .i file with following output:

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: /opt/src/gcc-9.1.0/configure --prefix=/opt --disable-multilib
--enable-languages=c,c++,lto --with-arch=native --with-system-zlib
Thread model: posix
gcc version 9.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-pthread' '-Wno-unused-result' '-Wsign-compare' '-D'
'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall' '-fdata-sections' '-flto' '-march=native'
'-s' '-fPIC' '-c' '-o' 'build/temp.linux-x86_64-3.7/ti/cache/_time.o' '-g0'
 /opt/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/cc1 -fpreprocessed _time.i
-march=x86-64 -mmmx -mno-3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16
-msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-pconfig
-mno-wbnoinvd -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt
-mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw
-mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx
-mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2
-mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri
-mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic -quiet
-dumpbase _time.i -auxbase-strip build/temp.linux-x86_64-3.7/ti/cache/_time.o
-g -g0 -O3 -Wno-unused-result -Wsign-compare -Wall -version -fwrapv
-fdata-sections -flto -fPIC -o /tmp/cchXskmr.s
GNU C17 (GCC) version 9.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.1.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 9.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.1.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
: internal compiler error: in build_common_tree_nodes, at
tree.c:10521

[Bug c/90628] __builtin_mul_overflow writes to const qualified integer

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
-Wdiscarded-qualifiers is for when the prototype requires pointer to non-const
and pointer to const is passed, which is the case for the clang style builtins,
but not for __builtin_{add,sub,mul}_overflow, where the function is
type-generic.
So I think the error is better.

[Bug c/90628] __builtin_mul_overflow writes to const qualified integer

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
I wonder if in C it should be controlled by -Wdiscarded-qualifiers. I am happy
with the unconditional error, just asking.

[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
It's actually cunroll that exposes the issue in zbufclip.  Ah, oops.

[Bug c/90628] __builtin_mul_overflow writes to const qualified integer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46416=edit
gcc10-pr90628.patch

Untested fix.  I think we should apply this to GCC10+ only.

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to bogi788 from comment #2)
> Created attachment 46414 [details]
> gcc 8.3.0 preprocessed source
> 
> The .i file was generated using gcc 8.3.0, since (as mentioned in the
> bugreport) gcc 9.1.0 writes an almost empty file.

Do you see the ICE if you use 8.3.0 generated file? Can you please provide
output of --verbose?

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[marxin at gcc dot gnu.org]

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

--- Comment #29 from Martin Liška  ---
(In reply to Thomas Koenig from comment #28)
> https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports
> the same symptoms for netcdf-fortran-4.4.5, presumably due
> to the same issue.
> 
> I'll try to fix that one and then see if the SPEC failure disappears
> along with it.
> 
> Martin, one additional question: When you step up from the segfault
> in the executable, is an array constructor passed as an argument
> somewhere up the call chain?  This is what appears to cause the trouble
> int netcdf.

How can I investigate that? Backtrace:

#0  0x008f706c in netcdf::nf90_put_var_1d_eightbytereal (ncid=7,
varid=23, values=..., start=, count=, 
stride=, map=...) at
netcdf_expanded.f90:1471
#1  0x00453a94 in pionfput_mod::put_var_1d_double (file=..., varid=23,
ival=...) at pionfput_mod.fppized.f90:1476
#2  0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=...,
vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468
#3  0x005be633 in cam_history::h_define (restart=4294949912, t=-17380)
at cam_history.fppized.f90:3822
#4  cam_history::wshist (rgnht_in=) at cam_history.fppized.f90:4461
#5  0x007811dc in cam_comp::cam_run4 (cam_out=..., cam_in=...,
rstwr=.FALSE., nlend=.FALSE., yr_spec=0, mon_spec=1, day_spec=1, sec_spec=1800)
at cam_comp.fppized.f90:325
#6  0x0079d809 in atm_comp_mct::atm_run_mct (eclock=..., cdata_a=...,
x2a_a=..., a2x_a=...) at atm_comp_mct.fppized.f90:513
#7  0x007deb03 in ccsm_comp_mod::ccsm_run () at
ccsm_comp_mod.fppized.f90:2408
#8  0x00403772 in ccsm_driver () at ccsm_driver.fppized.f90:58
#9  main (argc=argc@entry=1, argv=0x7fffdffe) at ccsm_driver.fppized.f90:25
#10 0x779b6b7b in __libc_start_main (main=0x403740 , argc=1,
argv=0x7fffdb98, init=, fini=,
rtld_fini=, stack_end=0x7fffdb88) at ../csu/libc-start.c:308
#11 0x004037ba in _start () at ../sysdeps/x86_64/start.S:120

#2  0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=...,
vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468
2468ierr = put_var_1d_double (File, vardesc%varid, ival)
(gdb) info locals 
ierr = 

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[bogi788 at hotmail dot com]

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

--- Comment #3 from bogi788 at hotmail dot com ---
Created attachment 46415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46415=edit
gcc 9.1.0 preprocessed source

the same file preprocessed with gcc 9.1.0, though i doubt it'll be much help.

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[bogi788 at hotmail dot com]

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

--- Comment #2 from bogi788 at hotmail dot com ---
Created attachment 46414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46414=edit
gcc 8.3.0 preprocessed source

The .i file was generated using gcc 8.3.0, since (as mentioned in the
bugreport) gcc 9.1.0 writes an almost empty file.

[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
GCC 7, 8 and 9 for me output

(1,1.46292e-09)
2147483647 2147483648
 (-1,7.77156e-16) (-1,-1.46292e-09)

(1.55377,0.643594)
(1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594)

(1.55377,0.643594)
(1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594)

(1.55377,0.643594)
(1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594)

if this is the correct result this is FIXED.  I can confirm your
reported result with GCC 4.8 but as said that's out of maintainance.
The change in output occurs with GCC 6 so that might be the version
this was fixed.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #28 from Thomas Koenig  ---
https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports
the same symptoms for netcdf-fortran-4.4.5, presumably due
to the same issue.

I'll try to fix that one and then see if the SPEC failure disappears
along with it.

Martin, one additional question: When you step up from the segfault
in the executable, is an array constructor passed as an argument
somewhere up the call chain?  This is what appears to cause the trouble
int netcdf.

[Bug c++/90640] -Wpointer-arith appears to be enabled by default, but is not reported as enabled by --help

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Liška  ---
Fixed on trunk in r270788.

[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug libgomp/90641] New: libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 90641
   Summary: libgomp.c-c++-common/lastprivate-conditional-1.c etc
FAIL
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-solaris2.11

The new libgomp.c-c++-common/lastprivate-conditional-[12].c tests FAIL on
32-bit
SPARC:

+FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-1.c execution
test
+FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-2.c execution
test
+FAIL: libgomp.c++/../libgomp.c-c++-common/lastprivate-conditional-1.c
execution test
+FAIL: libgomp.c++/../libgomp.c-c++-common/lastprivate-conditional-2.c
execution test

Thread 98 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 11 (LWP 11)]
0x000132b0 in foo ()
(gdb) where
#0  0x000132b0 in foo ()
#1  0xff04f22c in gomp_thread_start (xdata=0xffbfcd34)
at /vol/gcc/src/hg/trunk/local/libgomp/team.c:123
#2  0xfec54828 in _lwp_start () from /lib/libc.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

SIGSEGV above is due a gdb bug, this is really SIGBUS according to truss

0x000132b0 in foo ()
1: x/i $pc
=> 0x132b0 :  sttw  %o0, [ %l0 ]
(gdb) p/x $o0
$1 = 0x0
(gdb) p/x $l0
$2 = 0x2515c

sttw requires 8-byte alignment, so this might be an issue on other
strict-alignment
targets, too.

[Bug c++/90631] this statement may fall through

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-05-27
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The place of the ICE suggests a problem in target code.  Please provide
preprocessed source, the attached has #include directives.