date:20230510

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

2023-05-10 Thread aldyh at gcc dot gnu.org via Gcc-bugs

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

--- Comment #35 from Aldy Hernandez  ---
We could also tweak the number of sub-ranges.  8 (??) also sounds good for a
few percent less in performance drop, if we care.

p.s. I did try the auto_vec thing for a 25% loss in VRP performance, even when
using address(), reserve(), etc.  I may have gotten something wrong, but it
didn't look promising.  I could post my attempt and someone could take it from
there, but I think the one irange approach with sensible defaults that
automatically grow to MAX, better.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

2023-05-10 Thread aldyh at gcc dot gnu.org via Gcc-bugs

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

--- Comment #34 from Aldy Hernandez  ---
Excellent ideas!

For that matter, we may get away with defaulting to 3 sub-ranges and always
resizing as needed (up to MAX).  Needing more than 3 sub-ranges is so rare
(less than 0.5% of the time), that the penalty will be small.

Furthermore, these defaults are sensible enough that we could nuke int_range
altogether and have irange have this small [3*2] array.  After all, most uses
of int_range now are int_range_max, since we never know the size of the
range (except in rare cases such as boolean_type_node, etc).  This would
simplify the code and get rid of the annoying templates which I hate.  No need
for int_range_max, or int_range, etc.  Just plain irange.

This would give us an irange of 592 bytes compared to 40912 for int_range_max
currently.  Plus, it's not that far away from int_range<2> which currently is
432 bytes, and as I mentioned, barely happens as we mostly use int_range_max.

I think this is a nice trade off.  Cleaner more flexible code, without
templates.

Oh... preliminary tests show it's a 5% penalty for VRP, which is more than
covered by our 13.22% improvement (plus Andrew's cache improvements) to VRP.

[Bug debug/109805] LTO affecting -fdebug-prefix-map

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Let's reopen this one for a few.

[Bug debug/109805] LTO affecting -fdebug-prefix-map

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 87726.

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

[Bug debug/87726] -fdebug-prefix-map doesn't work with lto

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
>it's 1.6MB, so it was impossible to attach them here uncompressed

Can you try to compress it and attach it?

[Bug c++/109806] New: 13.1.0 cc1plus stack smashing crash with C array of complex structs

2023-05-10 Thread amy at amyspark dot me via Gcc-bugs

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

Bug ID: 109806
   Summary: 13.1.0 cc1plus stack smashing crash with C array of
complex structs
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amy at amyspark dot me
  Target Milestone: ---

Hi,

Coming from
https://github.com/msys2/MINGW-packages/pull/16968#issuecomment-1541465457.
I've found a crash in cc1plus 13.1.0 when building an array of ~68 structs in
C++. The crash yields no report or crash handling, it just causes g++  to
return exit code 1.

However, I was able to trap the cc1plus execution line, and then run it
manually under GDB. This yielded a symbolicated stacktrace that I've uploaded
along with the preprocessed file (it's 1.6MB, so it was impossible to attach
them here uncompressed):

https://gist.github.com/amyspark/be93638fc5b5779594dd138aa8995860

GCC version data:

Using built-in specs.
COLLECT_GCC=D:\msys64\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.1.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/ucrt64/include --libexecdir=/ucrt64/lib
--enable-bootstrap --enable-checking=release --with-arch=nocona
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp
--disable-multilib --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-pkgversion=Rev4, Built by MSYS2 project
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --enable-libstdcxx-debug --with-boot-ldflags="-static-libstdc++"
--with-stage1-ldflags="-static-libstdc++"
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Rev4, Built by MSYS2 project) 

Prior to https://github.com/msys2/MINGW-packages/pull/17094, the CFLAGS value
was (I added debug !strip to the PKGBUILD options to get debugging symbols):

-g -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong -ggdb -Og
-ffile-prefix-map=/c/Users/Amalia/Desktop/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug/mingw-w64-gcc

[Bug debug/109805] LTO affecting -fdebug-prefix-map

2023-05-10 Thread sergiodj at sergiodj dot net via Gcc-bugs

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

--- Comment #1 from Sergio Durigan Junior  ---
The formatting for the example snippet got messed up.  Here's a fixed version:

$ echo 'int main(){}' > foo.c
$ ~/gcc/install/bin/gcc -c foo.c -O2 -g -flto=auto -ffat-lto-objects
-fdebug-prefix-map=`pwd`=/aaa -o foo
$ ~/gcc/install/bin/gcc foo -flto=auto -ffat-lto-objects -o bar

[Bug debug/109805] New: LTO affecting -fdebug-prefix-map

2023-05-10 Thread sergiodj at sergiodj dot net via Gcc-bugs

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

Bug ID: 109805
Summary: LTO affecting -fdebug-prefix-map
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sergiodj at sergiodj dot net
Target Milestone: ---

Hi,

In Ubuntu we use -fdebug-prefix-map to remap a package's build directory (which
contains random stuff) into a predictable path under /usr/src. This is done in
order to help debuginfod index the source code for our packages.

Things work very well, but I found a weird corner case involving LTO. The
affected package is vim. You can see the build logs for it here:

https://launchpadlibrarian.net/665520301/buildlog_ubuntu-mantic-amd64.vim_2%3A9.0.1378-2ubuntu1_BUILDING.txt.gz

As you can notice, we're using -fdebug-prefix-map and LTO for the build.

The problem is that the resulting debuginfo doesn't have the remaped directory.
I can replicate the issue locally, and at first I thought this was either bug
#108464 or #87726, but after some digging I'm convinced it's something else.
I've compiled gcc (GCC) 14.0.0 20230510 from the master branch
(608e7f3ab47fe746279c552c3574147aa3d8ee76), and I still can reproduce the
problem.

A simple reproducer for the problem follows:

$ echo 'int main(){}' > foo.c $ ~/gcc/install/bin/gcc -c foo.c -O2 -g
-flto=auto -ffat-lto-objects -fdebug-prefix-map=`pwd`=/aaa -o foo $
~/gcc/install/bin/gcc foo -flto=auto -ffat-lto-objects -o bar

81 matches

Mail list logo