[Bug target/108191] Add support to usage of *intrin.h without -mavx512f -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108191 --- Comment #4 from 罗勇刚(Yonggang Luo) --- (In reply to Richard Biener from comment #3) > I suppose the issue will be that __attribute__((target)) isn't supported by > MSVC? But indeed this isn't something we are going to support. Note > another way is to put the functions into different translation units. gcc is enough, no need care about msvc, msvc can support without attribute, we can use macro to deal with that.
[Bug target/108191] Add support to usage of *intrin.h without -mavx512f -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108191 Richard Biener changed: What|Removed |Added Severity|normal |enhancement Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- I suppose the issue will be that __attribute__((target)) isn't supported by MSVC? But indeed this isn't something we are going to support. Note another way is to put the functions into different translation units.
[Bug target/108191] Add support to usage of *intrin.h without -mavx512f -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108191
--- Comment #2 from 罗勇刚(Yonggang Luo) ---
(In reply to Jakub Jelinek from comment #1)
> You are lying to the compiler, don't. In GCC you can #include
> with SSE2 only and later in say __attribute__((target ("avx512cd")))
> function use avx512f/avx512cd intrinsics, no need to do the what you show
> above.
Can you be more specific, show me the code, thanks:)
[Bug tree-optimization/108187] False positive -Wfree-nonheap-object on impossible path with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108187 --- Comment #1 from Richard Biener --- Well, between the store to ->source and the read from it is the call to dp_packet_use_afxdp which gets >packet as argument and thus needs to be treated as clobbering ->source. So GCC can indeed not know that ->source is DPBUF_AFXDP since the path is not provable impossible. dp_packet_use_afxdp doesn't even get a const struct dp_packet * argument (not that this would semantically change things in C).
[Bug target/108191] Add support to usage of *intrin.h without -mavx512f -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108191
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
You are lying to the compiler, don't. In GCC you can #include
with SSE2 only and later in say __attribute__((target ("avx512cd"))) function
use avx512f/avx512cd intrinsics, no need to do the what you show above.
[Bug libfortran/108056] [12 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from Richard Biener --- FIxed now.
[Bug libfortran/108056] [12 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:ed3e8a988e0ec5b926093e26dfeef1d8b7504d1f commit r12-9003-ged3e8a988e0ec5b926093e26dfeef1d8b7504d1f Author: Tobias Burnus Date: Wed Dec 21 07:55:22 2022 +0100 libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056] Since GCC 12, the conversion between the array descriptors formats - the internal (GFC) and the C binding one (CFI) - moved to the compiler itself such that the cfi_desc_to_gfc_desc/gfc_desc_to_cfi_desc functions are only used with older code (GCC 9 to 11). The newly added checks caused asserts as older code did not pass the proper values (e.g. real(4) as effective argument arrived as BT_ASSUME type as the effective type got lost inbetween). As proposed in the PR, revert to the GCC 11 version - known bugs is better than some fixes and new issues. Still, GCC 12 is much better in terms of TS29113 support and should really be used. This patch uses the current libgomp version of the GCC 11 branch, except it fixes the GFC version number (which is 0), uses calloc instead of malloc, and sets the lower bound to 1 instead of keeping it as is for CFI_attribute_other. (cherry picked from commit e205ec03f0794aeac3e8a89e947c12624d5a274e) (This cherry pick excludes an accidentally committed file, which was removed in follow-up commit 18af26fc375398f0a7cd7bae5aabebd447f8c899.) libgfortran/ChangeLog: PR libfortran/108056 * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc, gfc_desc_to_cfi_desc): Mostly revert to GCC 11 version for those backward-compatiblity-only functions.
[Bug libfortran/108056] [12 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|[12/13 Regression] backward |[12 Regression] backward |compatibility issue between |compatibility issue between |11 and 12 |11 and 12 Ever confirmed|0 |1 Last reconfirmed||2022-12-21 Priority|P3 |P1 Known to work||13.0 --- Comment #19 from Richard Biener --- Yep. Making P1 so we remember to fix it for 12.3.
[Bug middle-end/108073] [rs6000] sub-optimal float member accessing on struct parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108073 --- Comment #2 from Jiu Fu Guo --- (In reply to Surya Kumari Jangala from comment #1) > Hi Jiu Fu Guo, are you working on this bug? If not, I would like to take > this up. Thanks for your asking! I drafted an experimental patch. Welcome for any comments or refactoring :)
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #3 from AlexK --- (In reply to Andrew Pinski from comment #2) > Does this comparison failure happen if you set LANG environment variable to > C before doing a bootstrap? > If it please let us know which your environment variables so we can figure > out which sort is the issue. I didn't changed parameters especially for gcc build alexei@Aspire: echo $LANG ru_RU.UTF-8 alexei@Aspire: printenv SHELL=/bin/bash SESSION_MANAGER=local/Aspire:@/tmp/.ICE-unix/1540,unix/Aspire:/tmp/.ICE-unix/1540 QT_ACCESSIBILITY=1 COLORTERM=truecolor XDG_CONFIG_DIRS=/etc/xdg/xdg-cinnamon:/etc/xdg/ XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 NVM_INC=/home/alexei/.nvm/versions/node/v17.3.0/include/node GNOME_DESKTOP_SESSION_ID=this-is-deprecated PKG_CONFIG_PATH=/usr/local/lib/pkgconfig HISTSIZE= LANGUAGE=ru_RU LC_ADDRESS=ru_RU.UTF-8 JAVA_HOME=/opt/jdk LC_NAME=ru_RU.UTF-8 SSH_AUTH_SOCK=/run/user/1000/keyring/ssh CINNAMON_VERSION=5.2.7 DESKTOP_SESSION=cinnamon LC_MONETARY=ru_RU.UTF-8 SSH_AGENT_PID=1666 GOROOT_BOOTSTRAP=/mnt/Git/langs/go-1.19.2 GTK_MODULES=gail:atk-bridge XDG_SEAT=seat0 PWD=/mnt/Git/apt-build/build/gcc/gcc NIX_PROFILES=/nix/var/nix/profiles/default /home/alexei/.nix-profile XDG_SESSION_DESKTOP=cinnamon LOGNAME=alexei QT_QPA_PLATFORMTHEME=qt5ct XDG_SESSION_TYPE=x11 MANPATH=/home/alexei/.nvm/versions/node/v17.3.0/share/man:/opt/jdk/man GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 XORG_PREFIX=/usr/local XAUTHORITY=/home/alexei/.Xauthority XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/alexei GJS_DEBUG_TOPICS=JS ERROR;JS LOG GDM_LANG=ru HOME=/home/alexei LC_PAPER=ru_RU.UTF-8 LANG=ru_RU.UTF-8 HISTFILE=/home/alexei/.bash_eternal_history LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90: XDG_CURRENT_DESKTOP=X-Cinnamon VTE_VERSION=6003 NIX_SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/2a3caa56_4eff_4c17_a98d_338d453d0812 CPP_INCLUDE_PATH=:/usr/local/include GOROOT=/mnt/Git/langs/go XORG_CONFIG=--prefix=/usr/local --sysconfdir=/etc --localstatedir=/var --disable-static GJS_DEBUG_OUTPUT=stderr NVM_DIR=/home/alexei/.nvm LESSCLOSE=/usr/bin/lesspipe %s %s XDG_SESSION_CLASS=user TERM=xterm-256color LC_IDENTIFICATION=ru_RU.UTF-8 GTK_OVERLAY_SCROLLING=1 ACLOCAL_PATH=/usr/local/share/aclocal LESSOPEN=| /usr/bin/lesspipe %s LIBVIRT_DEFAULT_URI=qemu:///system USER=alexei GNOME_TERMINAL_SERVICE=:1.168 DISPLAY=:0 SHLVL=1 NVM_CD_FLAGS= LC_TELEPHONE=ru_RU.UTF-8 LC_MEASUREMENT=ru_RU.UTF-8 XDG_VTNR=7 XDG_SESSION_ID=c1 PAPERSIZE=a4 CLASSPATH=. LD_LIBRARY_PATH=:/usr/local/lib XDG_RUNTIME_DIR=/run/user/1000 PS1=\[\e]0;\u@\h: \w\a\]\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] \[\033[00;32m\]$(git_branch)\[\033[00m\]$ LC_TIME=ru_RU.UTF-8 GTK3_MODULES=xapp-gtk3-module XDG_DATA_DIRS=/usr/share/cinnamon:/usr/share/gnome:/home/alexei/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/share/:/var/lib/snapd/desktop
[Bug testsuite/108192] New: g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 Bug ID: 108192 Summary: g++.dg/cet-notrack-1.C searching for wrong function on mingw Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54139=edit cet-notrack-1.s g++.dg/cet-notrack-1.C Tries to find 'call puts()' in the asm after calling printf() on the c++ side. On Mingw, we do magic things with converting printf() into __mingw_ variants to support MS style printf and other things. So the assembler dump on mingw results in a call to __mingw_vfprintf in this particular case. It would likely be possible to fix the testcase by searching for "call __mingw_*printf" or something, but I'm curious if this is really a case of a missed optimization. The strings in question are simple string literals, so we don't care about mingw or ms special versions of printf, and a call to puts should be fine. I don't know if this testcase is specifically trying to validate that optimization, but it at least indirectly revealed it. Asm attached.
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #5 from nightstrike --- Created attachment 54138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54138=edit avx512vl-pr54700-1b.s
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #4 from nightstrike --- Created attachment 54137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54137=edit avx512vl-pr54700-1a.s
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #3 from nightstrike --- Created attachment 54136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54136=edit avx2-pr54700-1.s
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #2 from Andrew Pinski --- This is most likely because of the ABI difference between windows and elf targets. __v16qi is passed via memory location on windows but on elf targets it is passed via regsiter ...
[Bug c/108191] New: Add support to usage of *intrin.h without -mavx512f -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108191
Bug ID: 108191
Summary: Add support to usage of *intrin.h without -mavx512f
-mavx512cd
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luoyonggang at gmail dot com
Target Milestone: ---
This is for getting the following command to be works
```
gcc -fPIC -O2 -D__SSE3__=1 -D__SSSE3__=1 \
-D__SSE4_1__=1 -D__SSE4_2__=1 -D__SSE4A__=1 \
-D__POPCNT__=1 -D__XSAVE__=1 -D__CRC32__=1 \
-D__AVX__=1 -D__AVX2__=1 \
-D__FP_FAST_FMAF32=1 \
-D__FP_FAST_FMAF64=1 \
-D__FP_FAST_FMAF=1 \
-D__FP_FAST_FMAF32x=1 \
-D__AVX512F__=1 -D__AVX512CD__=1 test.c
```
That is generating code for SSE2 only, and we can using
#include
by using runtime flags.
Indeed, MSVC are aready can did that, if gcc can also support for that, we can
reduce the usage of inline assembly, because MSVC(x64) doesn't support for
inline assembly, so that we can reduce the code complex
The content of test.c is:
```
#if defined(_MSC_VER)
#include
#else
#include
#endif
#include
static inline int
util_iround(float f)
{
__m128 m = _mm_set_ss(f);
return _mm_cvtss_i32(m);
}
int util_iround_outside(int x, float y) {
return x + util_iround(y);
}
```
The compile error is something like:
```
In file included from
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/immintrin.h:35,
from
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/x86intrin.h:32,
from test.c:4:
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/pmmintrin.h:
In function '_mm_addsub_ps':
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/pmmintrin.h:53:3:
error: cannot convert a value of type 'int' to vector type '__vector(4) float'
which has different size
53 | return (__m128) __builtin_ia32_addsubps ((__v4sf)__X, (__v4sf)__Y);
| ^~
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/pmmintrin.h:
In function '_mm_hadd_ps':
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/pmmintrin.h:59:3:
error: cannot convert a value of type 'int' to vector type '__vector(4) float'
which has different size
59 | return (__m128) __builtin_ia32_haddps ((__v4sf)__X, (__v4sf)__Y);
| ^~
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/pmmintrin.h:
In function '_mm_hsub_ps':
C:/CI-Tools/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/12.2.0/include/pmmintrin.h:65:3:
error: cannot convert a value of type 'int' to vector type '__vector(4) float'
which has different size
65 | return (__m128) __builtin_ia32_hsubps ((__v4sf)__X, (__v4sf)__Y);
```
[Bug testsuite/108190] Various testsuite asm fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #1 from nightstrike --- Created attachment 54135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54135=edit avx-pr54700-1.s
[Bug testsuite/108190] New: Various testsuite asm fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 Bug ID: 108190 Summary: Various testsuite asm fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54134=edit asm output 1 The following are a collection of failures from running PR54700 tests on a linux to mingw cross compiler under Wine 7.20: FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-not pcmpgt[bdq] FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-times pblendvb 2 FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-times blendvps 4 FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-times blendvpd 4 FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-not vpcmpgt[bdq] FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-times vpblendvb 2 FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-times vblendvps 4 FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-times vblendvpd 4 FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-not vpcmpgt[bdq] FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vpblendvb 2 FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vblendvps 4 FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vblendvpd 4 FAIL: g++.target/i386/avx512vl-pr54700-1a.C scan-assembler-times vpblendvb 2 FAIL: g++.target/i386/avx512vl-pr54700-1b.C scan-assembler-times pblendvb 2 I don't know if it's helpful, but these are the /proc/cpuinfo flags on the cpus running under wine on an Intel(R) Xeon(R) Gold 6230: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch _perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_ mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke avx512_vnni md_clear flush_l1d arch_capabilities
[Bug testsuite/108152] gcc.dg/pr71558.c fails for LLP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152
--- Comment #2 from nightstrike ---
(In reply to Andrew Pinski from comment #1)
> { dg-options "" }
That would remove every option, no? Do others matter, like -pedantic, or
whatever else is there?
[Bug target/106736] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #13 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:282462b39584ae49eaaa6f53bd44b6cfdc4ccbcb
commit r13-4814-g282462b39584ae49eaaa6f53bd44b6cfdc4ccbcb
Author: Kewen Lin
Date: Tue Dec 20 21:02:08 2022 -0600
rs6000: Raise error for __vector_{quad,pair} uses without MMA enabled
[PR106736]
As PR106736 shows, it's unexpected to use __vector_quad and
__vector_pair types without MMA support, it would cause ICE
when expanding the corresponding assignment. We can't guard
these built-in types registering under MMA support as Peter
pointed out in that PR, because the registering is global,
it doesn't work for target pragma/attribute support with MMA
enabled. The existing verify_type_context mentioned in [2]
can help to make the diagnostics invalid built-in type uses
better, but as Richard pointed out in [4], it can't deal with
all cases. As the discussions in [1][3], this patch is to
check the invalid use of built-in types __vector_quad and
__vector_pair in mov pattern of OOmode and XOmode, on the
currently being expanded gimple assignment statement. It
still puts an assertion in else arm rather than just makes
it go through, it's to ensure we can catch any other possible
unexpected cases in time if there are.
[1] https://gcc.gnu.org/pipermail/gcc/2022-December/240218.html
[2] https://gcc.gnu.org/pipermail/gcc/2022-December/240220.html
[3] https://gcc.gnu.org/pipermail/gcc/2022-December/240223.html
[4] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608083.html
PR target/106736
gcc/ChangeLog:
* config/rs6000/mma.md (define_expand movoo): Call function
rs6000_opaque_type_invalid_use_p to check and emit error message
for
the invalid use of opaque type.
(define_expand movxo): Likewise.
* config/rs6000/rs6000-protos.h
(rs6000_opaque_type_invalid_use_p): New function declaration.
(currently_expanding_gimple_stmt): New extern declaration.
* config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): New
function.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr106736-1.c: New test.
* gcc.target/powerpc/pr106736-2.c: Likewise.
* gcc.target/powerpc/pr106736-3.c: Likewise.
* gcc.target/powerpc/pr106736-4.c: Likewise.
* gcc.target/powerpc/pr106736-5.c: Likewise.
[Bug target/106339] [13 Regression] ICE in exact_div, at poly-int.h:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106339 --- Comment #3 from Arseny Solokha --- Indeed. And I failed to come up w/ an alternative testcase so far.
[Bug c++/84471] Debugger jumps back to lambda capture location every time a captured variable is odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:302485a70a33f3a86e85ad9051de2b51c5dc0bc0 commit r13-4812-g302485a70a33f3a86e85ad9051de2b51c5dc0bc0 Author: Jason Merrill Date: Thu Dec 1 22:58:28 2022 -0500 c++: source position of lambda captures [PR84471] If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of that variable looks like it has that location, which leads to the debugger jumping back and forth for both lambdas and structured bindings. Rather than fix all the uses, it seems simplest to remove any EXPR_LOCATION when setting DECL_VALUE_EXPR. So the cp/ hunks aren't necessary, but they avoid the need to unshare to remove the location. PR c++/84471 PR c++/107504 gcc/cp/ChangeLog: * coroutines.cc (transform_local_var_uses): Don't specify a location for DECL_VALUE_EXPR. * decl.cc (cp_finish_decomp): Likewise. gcc/ChangeLog: * fold-const.cc (protected_set_expr_location_unshare): Not static. * tree.h: Declare it. * tree.cc (decl_value_expr_insert): Use it. include/ChangeLog: * ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/value-expr1.C: New test. * g++.dg/tree-ssa/value-expr2.C: New test. * g++.dg/analyzer/pr93212.C: Move warning.
[Bug c++/107504] Debugger jumps back to structured binding declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:302485a70a33f3a86e85ad9051de2b51c5dc0bc0 commit r13-4812-g302485a70a33f3a86e85ad9051de2b51c5dc0bc0 Author: Jason Merrill Date: Thu Dec 1 22:58:28 2022 -0500 c++: source position of lambda captures [PR84471] If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of that variable looks like it has that location, which leads to the debugger jumping back and forth for both lambdas and structured bindings. Rather than fix all the uses, it seems simplest to remove any EXPR_LOCATION when setting DECL_VALUE_EXPR. So the cp/ hunks aren't necessary, but they avoid the need to unshare to remove the location. PR c++/84471 PR c++/107504 gcc/cp/ChangeLog: * coroutines.cc (transform_local_var_uses): Don't specify a location for DECL_VALUE_EXPR. * decl.cc (cp_finish_decomp): Likewise. gcc/ChangeLog: * fold-const.cc (protected_set_expr_location_unshare): Not static. * tree.h: Declare it. * tree.cc (decl_value_expr_insert): Use it. include/ChangeLog: * ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/value-expr1.C: New test. * g++.dg/tree-ssa/value-expr2.C: New test. * g++.dg/analyzer/pr93212.C: Move warning.
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 --- Comment #13 from Jan-Benedict Glaw --- GCC 13 (as of g:02c031088ac0bbf) triggers this for Linux's kallsys.c (f9ff5644bcc04221bae56f922) for ia64.
[Bug rtl-optimization/90282] internal compiler error: qsort checking failed in snapshot-20190429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282 --- Comment #14 from Jan-Benedict Glaw --- GCC 13 (as of g:02c031088ac0bbf) triggers this for Linux's kallsys.c (f9ff5644bcc04221bae56f922) for ia64.
[Bug c++/101886] [11/12 Regression][concepts TS] ICE with auto as template argument since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8aa045c97485d75e0b6eb1068464c0ddaa6beacb commit r13-4810-g8aa045c97485d75e0b6eb1068464c0ddaa6beacb Author: Patrick Palka Date: Tue Dec 20 17:02:37 2022 -0500 c++, tree: walk TREE_VEC (and VECTOR_CST) in natural order [PR101886] Unfortunately the extract_autos_r fix in r13-4799-ga7c8036b26082d is derailed by the fact that walk_tree_1 currently walks the elements of a TREE_VEC in reverse, which means for A in the below testcase extract_autos_r ends up adjusting the TEMPLATE_TYPE_IDX of the first auto instead of the second one, and the first auto is the canonical auto of level 2 (and index 0), so we rightfully trigger the sanity check added in that commit. It seems TREE_VEC and VECTOR_CST are the only trees we walk in reverse, and this has been the case since r21884 whence the original version of walk_tree_1 was introduced. But that's arguably unnatural and not consistent with how we walk all other compound trees such as CONSTRUCTORs and EXPR_P trees in forward order. So this patch makes walk_tree_1 walk TREE_VEC (and VECTOR_CST) in forward order as well, which fixes the testcase. Doing so revealed that keep_template_parm grows the list of found template parameters from the front, which previously compensated for the TREE_VEC behavior, so now we should grow it from the back. PR c++/101886 gcc/cp/ChangeLog: * pt.cc (find_template_parameter_info::parm_list_tail): New data member. (keep_template_parm): Use parm_list_tail to append rather than prepend to parm_list. gcc/ChangeLog: * tree.cc (walk_tree_1) : Walk the elements in forward instead of reverse order. : Likewise. gcc/testsuite/ChangeLog: * g++.dg/concepts/diagnostic12.C: Adjust expected order of template parameters within pretty printed parameter mapping. * g++.dg/concepts/auto6.C: New test.
[Bug fortran/107144] ICE in gfc_get_symbol_decl, at fortran/trans-decl.cc:1623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107144 --- Comment #2 from anlauf at gcc dot gnu.org --- Placing the subroutine into a module avoids ICE. Could this pr be related to pr107141?
[Bug fortran/95375] ICE in add_use_op, Error: mismatching comparison operand types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95375 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13. Closing. Thanks for the report!
[Bug fortran/95375] ICE in add_use_op, Error: mismatching comparison operand types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95375 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:aed5584ff6891560dc567e54517b9722dadc503e commit r13-4809-gaed5584ff6891560dc567e54517b9722dadc503e Author: Harald Anlauf Date: Tue Dec 20 21:17:08 2022 +0100 Fortran: a C interoperable function cannot have the CLASS attribute [PR95375] gcc/fortran/ChangeLog: PR fortran/95375 * decl.cc (verify_bind_c_sym): Extend interoperability check to CLASS variables. gcc/testsuite/ChangeLog: PR fortran/95375 * gfortran.dg/bind_c_procs_4.f90: New test.
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #11 from Gaius Mulley --- Many thanks for the analysis. Taking your idea and assuming that Sym 6114 is a procedure then I think the correction is: PROCEDURE IsExternal (sym: CARDINAL) : BOOLEAN ; VAR mod: CARDINAL ; BEGIN (* new code starts here. *) IF IsProcedure (sym) AND IsExtern (sym) THEN RETURN TRUE END ; (* end of new code. *) mod := GetScope(sym) ; REPEAT IF mod=NulSym THEN RETURN( FALSE ) ELSIF IsDefImp(mod) THEN RETURN( mod#GetMainModule() ) END ; mod := GetScope(mod) UNTIL mod=NulSym ; RETURN( FALSE ) END IsExternal ; In gcc/m2/gm2-compiler/SymbolTable.mod procedures can be queried as IsExtern. The ctors are special case created in gcc/m2/gm2-compiler/M2Scaffold.mod. It looks as if the special case might not have been tested in IsExternal.
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #10 from Andrew Pinski --- (In reply to James Hilliard from comment #8) > Yeah, clang with -std=gnu17 -pedantic doesn't even complain at all from the > looks of it. Does it make sense to allow disabling this specific warning in > GCC? No it does not make sense at all to disable this specific warning; maybe request clang implement the warning too. > What would be the correct way to fix these in bpf-next? Move the struct definition outside of the function definition? You could ask the bpf mailing list of what is the fix they would like to see for this questionable code.
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #9 from James Hilliard --- (In reply to Andrew Pinski from comment #5) > Also Clang does not implement this warning at all. > > It is a bug in bpf-next really. What would be the correct way to fix these in bpf-next?
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189
--- Comment #8 from James Hilliard ---
(In reply to Andrew Pinski from comment #7)
> Yes the warning is really still correct even if a closer testcase would be:
> ```
> int f(struct {int t;} *b)
> {
> return b->t;
> }
>
> int f1(void *a)
> {
> return f(a);
> }
> ```
> I am actually shocked clang didn't implement this warning since there is no
> type which is compatible with the typeof *b outside of function f.
Yeah, clang with -std=gnu17 -pedantic doesn't even complain at all from the
looks of it. Does it make sense to allow disabling this specific warning in
GCC?
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189
--- Comment #7 from Andrew Pinski ---
Yes the warning is really still correct even if a closer testcase would be:
```
int f(struct {int t;} *b)
{
return b->t;
}
int f1(void *a)
{
return f(a);
}
```
I am actually shocked clang didn't implement this warning since there is no
type which is compatible with the typeof *b outside of function f.
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |MOVED
--- Comment #6 from Andrew Pinski ---
clang does not implement the warning even though it is a correct warning.
Witness:
int f(struct {int t;} b)
{
return b.t;
}
int f1(void)
{
return f((struct {int t;}){1});
}
Is rejected.
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #5 from Andrew Pinski --- Also Clang does not implement this warning at all. It is a bug in bpf-next really.
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #4 from Andrew Pinski --- Also Clang does not implement this warning at all. It is a bug in bpf-next really.
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #10 from Iain Sandoe --- It looks to me that we never check if Sym is a definition/implementation - only that the containing scope is. I probably miss something subtle - but perhaps IF NOT IsDefImp(Sym) RETURN ( TRUE ) before the mod := line ? (* IsExternal - *) PROCEDURE IsExternal (sym: CARDINAL) : BOOLEAN ; VAR mod: CARDINAL ; BEGIN mod := GetScope(sym) ; REPEAT IF mod=NulSym THEN RETURN( FALSE ) ELSIF IsDefImp(mod) THEN RETURN( mod#GetMainModule() ) END ; mod := GetScope(mod) UNTIL mod=NulSym ; RETURN( FALSE ) END IsExternal ;
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #3 from Andrew Pinski --- GCC does not implement all of C2X yet.
[Bug fortran/95375] ICE in add_use_op, Error: mismatching comparison operand types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95375 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058669.html
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189
--- Comment #2 from James Hilliard ---
(In reply to Andrew Pinski from comment #1)
> The error is correct at least for C before C23.
Hmm, seeing it with -std=gnu2x passed still:
/home/buildroot/opt/cross/bin/bpf-gcc -g -Werror -D__TARGET_ARCH_x86
-mlittle-endian
-I/home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include
-I/home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/include
-I/home/buildroot/bpf-next/tools/testing/selftests/bpf
-I/home/buildroot/bpf-next/tools/include/uapi
-I/home/buildroot/bpf-next/tools/testing/selftests/usr/include -gbtf -mco-re
-Wno-error=attributes -Wno-error=address-of-packed-member
-Wno-compare-distinct-pointer-types -std=gnu2x -idirafter
/usr/lib/gcc/x86_64-linux-gnu/11/include -idirafter /usr/local/include
-idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -nostdinc -O2
-c progs/btf_dump_test_case_bitfields.c -mcpu=v3 -o
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/btf_dump_test_case_bitfields.bpf.o
progs/btf_dump_test_case_bitfields.c:85:7: error: anonymous struct declared
inside parameter list will not be visible outside of this definition or
declaration [-Werror]
85 | int f(struct {
| ^~
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #1 from Andrew Pinski --- The error is correct at least for C before C23.
[Bug target/108189] New: anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189
Bug ID: 108189
Summary: anonymous struct declared inside parameter list will
not be visible outside of this definition or
declaration
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: james.hilliard1 at gmail dot com
Target Milestone: ---
I'm seeing this error which does not occur in llvm for a bpf
test(btf_dump_test_case_bitfields.c) in bpf-next:
progs/btf_dump_test_case_bitfields.c:85:7: error: anonymous struct declared
inside parameter list will not be visible outside of this definition or
declaration [-Werror]
85 | int f(struct {
| ^~
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #9 from Iain Sandoe --- So we do set _M2_termios_ctor Symbol to extern. But then here: PreAddModGcc (Sym, BuildEndFunctionDeclaration (begin, end, KeyToCharStar (GetFullSymName (Sym)), returnType, IsExternal (Sym), (* Extern relative to the main module. *) IsProcedureGccNested (Sym), (* Exported from the module where it was declared. *) IsExported (GetModuleWhereDeclared (Sym), Sym) OR IsExtern (Sym))) ; PopBinding(scope) ; "IsExternal (Sys)" returns false, because it thinks that the scope of _M2_termios_ctor is HelloMod. (lldb) p SymbolTable_GetScope(Sym) (unsigned int) $5 = 155 (lldb) p M2GCCDeclare_PrintSym(155) information about symbol: 155 == sym 155 IsModule (HelloWorld) (lldb) p Sym (unsigned int) $6 = 6114 (lldb) p M2GCCDeclare_PrintSym(6114) information about symbol: 6114 == sym 6114 IsProcedure (_M2_termios_ctor) scope HelloWorld:1 155 extern ctor declared in /source/test/hello.mod:1 So we create the decl assuming it exists in the TU .. which is the source of the wrong code.
[Bug c++/108116] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1074 since r12-6897-gdec8d0e5fa00ceb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c/94428] Reintroduce -Wzero-length-array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428 --- Comment #4 from qinzhao at gcc dot gnu.org --- a new warning -Wstrict-flex-arrays was added to gcc13. when using -Wstrict-flex-arrays -fstrict-flex-arrays=3 together, the new warning will report any misuse of zero-length arrays as flexible array members. I think this new warning could be a replacement of this -Wzero-length-array. therefore the warning -Wzero-length-array might not be needed anymore.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #10 from Gaius Mulley --- LGTM yes indeed, location_t should be CARDINAL
[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108056 --- Comment #18 from Jakub Jelinek --- So, fixed on trunk, to be backported later?
[Bug c++/108158] [11/12/13 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108158] [11/12/13 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Marek Polacek --- Mine then :(
[Bug target/108141] [13 Regression] gcc.target/i386/pr64110.c FAIL since r13-4727 on ia32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108141 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jakub Jelinek --- The change has been reverted, so this is no longer a regression.
[Bug c++/108158] [11/12/13 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-12-20 Status|UNCONFIRMED |NEW Keywords|needs-bisection | Ever confirmed|0 |1 Summary|[11/12/13 Regression] |[11/12/13 Regression] |modification of '...' is|modification of '...' is |not a constant expression |not a constant expression ||since r12-2304 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started to be rejected with r12-2304-ga42f8120442cf3ba25d621bed857b5be19019d0c aka PR101371 fix, which got later backported to 11 branch in r11-9710.
[Bug rtl-optimization/84345] [10/11/12/13 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345 --- Comment #18 from Andrew Pinski --- (In reply to Jan-Benedict Glaw from comment #17) > Just found this issue with GCC 13 (g:2dc5d6b1e7e) building the Linux kernel > for ia64 (--target=ia64-linux, with eg. the zx1_defconfig): That is a different issue, See PR 87281 and PR 90282 for the IA64 issues dealing with that.
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer since r13-2205-g14cfa01755a66afb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- .
[Bug tree-optimization/108137] [12/13 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137 --- Comment #5 from ucko at ncbi dot nlm.nih.gov --- > --- Comment #4 from Martin Liška --- > I can fix that. That would be great, thanks; I can fairly easily work around this bug in the file where I first hit it, but we have another (non-public) file that's much more severely affected. Our sysadmins are prepared to supply test installations incorporating any patches you draft.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #9 from Segher Boessenkool --- That patch looks good btw :-)
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #8 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #5) > So, I bet there must be some mismatch on whether M2Options_OverrideLocation > returns a signed or unsigned 32-bit value. > I believe the powerpc64le-linux ABI (and probably various other ABIs) > returns (and passes?) signed 32-bit values sign-extended from 32-bits to > 64-bits, and returns (and passes?) unsigned 32-bit values zero-extended from > 32-bits to 64-bits. ELFv2 says Follow these rules for parameter passing: [...] • Map simple integer types (char, short, int, long, enum) to a single doubleword. Sign or zero extend values shorter than a doubleword to a doubleword based on whether the source data type is signed or unsigned. (Older ABIs said just Simple integer types (char, short, int, long, enum) are mapped to a single doubleword. Values shorter than a doubleword are sign or zero extended as necessary.) > Say x86_64-linux doesn't do this, the upper 32 bits when passing or > returning 32-bit values are undefined. It in general is cheaper for the caller to extend than for the callee (it often can be done for free in the caller). It also saves code size. Finally, undefined bits in your calling convention easily cause problems (besides being wasteful of course).
[Bug c++/103346] ICE on template specialization via alias template with a non-type parameter pack, and fold expression on lambda calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103346 Patrick Palka changed: What|Removed |Added Known to work||13.0 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/104278] ICE with class non-type template parameter with a value depdenent constexpr call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104278 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Known to work||13.0 Status|NEW |ASSIGNED
[Bug c++/102553] ICE (seg fault) in strip_array_types with NTTP and template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Known to work||13.0 CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/102553] ICE (seg fault) in strip_array_types with NTTP and template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553
--- Comment #10 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:49b6b7ac3314843466395c4a194aa178c80e64f5
commit r13-4807-g49b6b7ac3314843466395c4a194aa178c80e64f5
Author: Patrick Palka
Date: Tue Dec 20 11:09:11 2022 -0500
c++: NTTP object wrapper substitution fixes [PR103346, ...]
This patch fixes some issues with substitution into a C++20 template
parameter object wrapper:
* The first testcase demonstrates a situation where the same_type_p
assert in relevant case of tsubst_copy doesn't hold, because (partial)
substitution of {int,} into the wrapper's TREE_TYPE yields A but
substitution into the underlying TEMPLATE_PARM_INDEX is a nop due to
tsubst's level==1/tf_partial early exit tests, hence TREE_TYPE in the
latter case remains A. So this patch just gets rid of the assert;
the type mismatch doesn't seem to be a problem in practice.
* In the second testcase, dependent substitution into the underlying
TEMPLATE_PARM_INDEX yields a CALL_EXPR with empty TREE_TYPE, which
tsubst_copy doesn't expect. This patch fixes this by handling empty
TREE_TYPE the same way as a non-const TREE_TYPE. Moreover, after
this substitution we're left with a VIEW_CONVERT_EXPR wrapping a
CALL_EXPR instead of a TEMPLATE_PARM_INDEX, which during the subsequent
non-dependent substitution tsubst_copy doesn't expect either. So
this patch also relaxes tsubst_copy to accept such VIEW_CONVERT_EXPR
too.
* In the third testcase, we end up never resolving the call to
f.modify() because tsubst_copy doesn't do overload resolution.
This patch fixes this by moving the handling of these
VIEW_CONVERT_EXPR wrappers from tsubst_copy to tsubst_copy_and_build.
For good measure tsubst_copy_and_build should also handle
REF_PARENTHESIZED_P wrappers instead of delegating to tsubst_copy.
PR c++/103346
PR c++/104278
PR c++/102553
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy) : Move the
handling of C++20 template parameter object wrappers to ...
(tsubst_copy_and_build) : ... here.
Accept non-TEMPLATE_PARM_INDEX inner operand. Handle empty
TREE_TYPE on substituted inner operand. Remove same_type_p
assert. Also handle REF_PARENTHESIZED_P VIEW_CONVERT_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class52a.C: New test.
* g++.dg/cpp2a/nontype-class53.C: New test.
* g++.dg/cpp2a/nontype-class54.C: New test.
* g++.dg/cpp2a/nontype-class55.C: New test.
[Bug c++/103346] ICE on template specialization via alias template with a non-type parameter pack, and fold expression on lambda calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103346
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:49b6b7ac3314843466395c4a194aa178c80e64f5
commit r13-4807-g49b6b7ac3314843466395c4a194aa178c80e64f5
Author: Patrick Palka
Date: Tue Dec 20 11:09:11 2022 -0500
c++: NTTP object wrapper substitution fixes [PR103346, ...]
This patch fixes some issues with substitution into a C++20 template
parameter object wrapper:
* The first testcase demonstrates a situation where the same_type_p
assert in relevant case of tsubst_copy doesn't hold, because (partial)
substitution of {int,} into the wrapper's TREE_TYPE yields A but
substitution into the underlying TEMPLATE_PARM_INDEX is a nop due to
tsubst's level==1/tf_partial early exit tests, hence TREE_TYPE in the
latter case remains A. So this patch just gets rid of the assert;
the type mismatch doesn't seem to be a problem in practice.
* In the second testcase, dependent substitution into the underlying
TEMPLATE_PARM_INDEX yields a CALL_EXPR with empty TREE_TYPE, which
tsubst_copy doesn't expect. This patch fixes this by handling empty
TREE_TYPE the same way as a non-const TREE_TYPE. Moreover, after
this substitution we're left with a VIEW_CONVERT_EXPR wrapping a
CALL_EXPR instead of a TEMPLATE_PARM_INDEX, which during the subsequent
non-dependent substitution tsubst_copy doesn't expect either. So
this patch also relaxes tsubst_copy to accept such VIEW_CONVERT_EXPR
too.
* In the third testcase, we end up never resolving the call to
f.modify() because tsubst_copy doesn't do overload resolution.
This patch fixes this by moving the handling of these
VIEW_CONVERT_EXPR wrappers from tsubst_copy to tsubst_copy_and_build.
For good measure tsubst_copy_and_build should also handle
REF_PARENTHESIZED_P wrappers instead of delegating to tsubst_copy.
PR c++/103346
PR c++/104278
PR c++/102553
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy) : Move the
handling of C++20 template parameter object wrappers to ...
(tsubst_copy_and_build) : ... here.
Accept non-TEMPLATE_PARM_INDEX inner operand. Handle empty
TREE_TYPE on substituted inner operand. Remove same_type_p
assert. Also handle REF_PARENTHESIZED_P VIEW_CONVERT_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class52a.C: New test.
* g++.dg/cpp2a/nontype-class53.C: New test.
* g++.dg/cpp2a/nontype-class54.C: New test.
* g++.dg/cpp2a/nontype-class55.C: New test.
[Bug c++/104278] ICE with class non-type template parameter with a value depdenent constexpr call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104278
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:49b6b7ac3314843466395c4a194aa178c80e64f5
commit r13-4807-g49b6b7ac3314843466395c4a194aa178c80e64f5
Author: Patrick Palka
Date: Tue Dec 20 11:09:11 2022 -0500
c++: NTTP object wrapper substitution fixes [PR103346, ...]
This patch fixes some issues with substitution into a C++20 template
parameter object wrapper:
* The first testcase demonstrates a situation where the same_type_p
assert in relevant case of tsubst_copy doesn't hold, because (partial)
substitution of {int,} into the wrapper's TREE_TYPE yields A but
substitution into the underlying TEMPLATE_PARM_INDEX is a nop due to
tsubst's level==1/tf_partial early exit tests, hence TREE_TYPE in the
latter case remains A. So this patch just gets rid of the assert;
the type mismatch doesn't seem to be a problem in practice.
* In the second testcase, dependent substitution into the underlying
TEMPLATE_PARM_INDEX yields a CALL_EXPR with empty TREE_TYPE, which
tsubst_copy doesn't expect. This patch fixes this by handling empty
TREE_TYPE the same way as a non-const TREE_TYPE. Moreover, after
this substitution we're left with a VIEW_CONVERT_EXPR wrapping a
CALL_EXPR instead of a TEMPLATE_PARM_INDEX, which during the subsequent
non-dependent substitution tsubst_copy doesn't expect either. So
this patch also relaxes tsubst_copy to accept such VIEW_CONVERT_EXPR
too.
* In the third testcase, we end up never resolving the call to
f.modify() because tsubst_copy doesn't do overload resolution.
This patch fixes this by moving the handling of these
VIEW_CONVERT_EXPR wrappers from tsubst_copy to tsubst_copy_and_build.
For good measure tsubst_copy_and_build should also handle
REF_PARENTHESIZED_P wrappers instead of delegating to tsubst_copy.
PR c++/103346
PR c++/104278
PR c++/102553
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy) : Move the
handling of C++20 template parameter object wrappers to ...
(tsubst_copy_and_build) : ... here.
Accept non-TEMPLATE_PARM_INDEX inner operand. Handle empty
TREE_TYPE on substituted inner operand. Remove same_type_p
assert. Also handle REF_PARENTHESIZED_P VIEW_CONVERT_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class52a.C: New test.
* g++.dg/cpp2a/nontype-class53.C: New test.
* g++.dg/cpp2a/nontype-class54.C: New test.
* g++.dg/cpp2a/nontype-class55.C: New test.
[Bug tree-optimization/107751] [11/12/13 regression] False positive -Wmaybe-uninitialized at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107751
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase (removes the templates, also now able to compile as C):
> typedef const int T1;
> typedef const int T2;
> void std_equal(T1* a1, T1* a2, T2* b1);
> void f() {
> int a[3] = {1, 2, 3};
> T1* x= a;
> T2* y= a;
> std_equal(x, x+3, y);
> }
It's also odd we diagnose x + 3 but not x + 2. We're using
ao_ref_init_from_ptr_and_size but that's not a good measure,
esp. for
/* Do not warn if the access is zero size or if it's fully outside
the object. */
poly_int64 decl_size;
if (known_size_p (ref.size)
&& known_eq (ref.max_size, ref.size)
&& (known_eq (ref.size, 0)
|| known_le (ref.offset + ref.size, 0)))
return NULL_TREE;
also given that this function doesn't do a good job at gettting at for
the IL at -O0 which is
:
a[0] = 1;
a[1] = 2;
a[2] = 3;
x_6 =
y_7 =
_1 = x_6 + 8;
std_equal (x_6, _1, y_7);
note that a function receiving x + O can adjust this pointer before reading
from it so using [x+O, +INF] as access range to find initialization isn't
the best thing to do.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 Andrew Pinski changed: What|Removed |Added CC||glex.spb at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 108188 has been marked as a duplicate of this bug. ***
[Bug libstdc++/108188] Segfault in compatibility-condvar.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108188 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- This is a uclibc specific issue. Maybe related to how unwinding is done. *** This bug has been marked as a duplicate of bug 105730 ***
[Bug target/107678] [13 Regression] Segfault in aarch64_fallback_frame_state when running SVE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #7 from Jakub Jelinek --- Created attachment 54133 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54133=edit gcc13-pr108153.patch Same in patch form. Let me test if that helps.
[Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ statically linked programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener --- Thus fixed.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #6 from Jakub Jelinek --- libcpp/cpplib.h has line-map.h:typedef unsigned int location_t; The modula 2 source has: FROM m2linemap IMPORT location_t ; ... PROCEDURE OverrideLocation (location: location_t) : location_t ; BEGIN IF ForcedLocation THEN RETURN( ForcedLocationValue ) ELSE RETURN( location ) END END OverrideLocation ; and TYPE location_t = INTEGER ; So, I just wonder if it shouldn't be location_t = CARDINAL ; instead.
[Bug c++/107575] [12/13 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in duplicate_decls, at cp/decl.cc:2605 since r12-8115-g791a968630b3846b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107575 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug target/107549] [13 Regression] heap-buffer-overflow in xt_true_regnum since r13-3376-g4f3f0296acbb99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107549 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 Jakub Jelinek changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- What fails is: ./cc1gm2 -msecure-plt -quiet -dumpbase SYSTEM.mod -dumpbase-ext .mod -mtune=power8 -mcpu=power8 -version -fpim -fno-scaffold-main -fno-scaffold-dynamic -fno-scaffold-static -fno-m2-plugin -fdump-system-exports -B ./ -B /usr/ppc64le-redhat-linux/bin/ -c -fpim -fno-scaffold-main -fno-scaffold-dynamic -fno-scaffold-static -fno-m2-plugin -fdump-system-exports -I ../../gcc/m2/gm2-libs -I /usr/lib/gcc/ppc64le-redhat-linux/13/m2/m2pim -I /usr/lib/gcc/ppc64le-redhat-linux/13/m2/m2log -I /usr/lib/gcc/ppc64le-redhat-linux/13/m2/m2iso ../../gcc/m2/gm2-libs/SYSTEM.mod -o /tmp/ccgDXY6u.s and the ICE is because m2assert_AssertLocation inlined into m2statement_BuildAssignmentTree sees a difference on M2Options_OverrideLocation (location) != location location (in $r30) is 0x8007, while M2Options_OverrideLocation returned (in $r3) 0x8007 instead. M2Options_OverrideLocation ends with 0x102396e0 <+32>:extsw r3,r3 before returning, so it clearly sign extends the 32-bit return value to 64-bit. And the caller compares whole 64-bits: 0x101c7488 : mr r30,r3 0x101c748c : mr r29,r4 0x101c7490 : mr r31,r5 0x101c7494 : ble 0x101c74a8 0x101c7498 : bl 0x102396c8 0x101c749c : nop => 0x101c74a0 : cmpdr3,r30 So, I bet there must be some mismatch on whether M2Options_OverrideLocation returns a signed or unsigned 32-bit value. I believe the powerpc64le-linux ABI (and probably various other ABIs) returns (and passes?) signed 32-bit values sign-extended from 32-bits to 64-bits, and returns (and passes?) unsigned 32-bit values zero-extended from 32-bits to 64-bits. Say x86_64-linux doesn't do this, the upper 32 bits when passing or returning 32-bit values are undefined.
[Bug tree-optimization/106842] [12/13 Regression] misleading warning : iteration X invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC||amacleod at redhat dot com
--- Comment #6 from Richard Biener ---
So I can confirm that the following avoids the bogus diagnostic on the GCC 12
branch but it will ICE when doing -fdump-tree-vrp-details like
t.c: In function 'main':
t.c:4:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in to_wide, at tree.h:6138
4 | int main(int argc, char** argv)
| ^~~~
0x1889919 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/rguenther/src/gcc-12-branch/gcc/tree.cc:8869
0xae7151 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/rguenther/src/gcc-12-branch/gcc/tree.h:3580
0xb68f93 wi::to_wide(tree_node const*)
/home/rguenther/src/gcc-12-branch/gcc/tree.h:6138
0xcdbc11 irange::upper_bound(unsigned int) const
/home/rguenther/src/gcc-12-branch/gcc/value-range.h:535
0xcdbc81 irange::upper_bound() const
/home/rguenther/src/gcc-12-branch/gcc/value-range.h:545
0x2ab34d3 operator_not_equal::op1_range(irange&, tree_node*, irange const&,
irange const&, tree_code) const
/home/rguenther/src/gcc-12-branch/gcc/range-op.cc:713
0x2952cfd gimple_range_calc_op1(irange&, gimple const*, irange const&, irange
const&)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range-gori.cc:77
0x29558a8 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range-gori.cc:1024
0x295493c gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*, fur_source&)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range-gori.cc:718
0x29566a2 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*,
range_query&)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range-gori.cc:1271
0x294639e ranger_cache::range_on_edge(irange&, edge_def*, tree_node*)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range-cache.cc:1083
0x2942993 gimple_ranger::dump_bb(_IO_FILE*, basic_block_def*)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range.cc:550
0x2942c11 gimple_ranger::dump(_IO_FILE*)
/home/rguenther/src/gcc-12-branch/gcc/gimple-range.cc:590
0x186618d execute_ranger_vrp(function*, bool)
/home/rguenther/src/gcc-12-branch/gcc/tree-vrp.cc:4343
because we dump (and invoke range compute!) for unreachable blocks which
eventually runs into code with not up-to-date SSA form. The patch should
save compile-time by not folding/substituting in regions that are not
reachable.
diff --git a/gcc/tree-ssa-propagate.cc b/gcc/tree-ssa-propagate.cc
index 976b035eeec..e669fc9b7cf 100644
--- a/gcc/tree-ssa-propagate.cc
+++ b/gcc/tree-ssa-propagate.cc
@@ -664,7 +664,7 @@ class substitute_and_fold_dom_walker : public dom_walker
public:
substitute_and_fold_dom_walker (cdi_direction direction,
class substitute_and_fold_engine *engine)
- : dom_walker (direction),
+ : dom_walker (direction, REACHABLE_BLOCKS),
something_changed (false),
substitute_and_fold_engine (engine)
{
@@ -952,7 +952,7 @@ substitute_and_fold_dom_walker::before_dom_children
(basic_block bb)
something_changed |= substitute_and_fold_engine->propagate_into_phi_args
(bb);
- return NULL;
+ return find_taken_edge (bb, NULL_TREE);
}
[Bug middle-end/106805] [13 Regression] Undue optimisation of floating-point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805 --- Comment #6 from Richard Biener --- Note phiopt turns some control-flow into straight-line code which is then also susceptible to code motion across the foo() calls, even if that's not what currently happens. So even preserving those stmts will still have them un-ordered with respect to the inspection of the FP exception state, that is, -frounding-math is known to be buggy.
[Bug libstdc++/108188] New: Segfault in compatibility-condvar.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108188
Bug ID: 108188
Summary: Segfault in compatibility-condvar.cc
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: glex.spb at gmail dot com
Target Milestone: ---
I'd like to report a regression in the libstdc++ that comes with GCC 12 series
(GCC 11 was OK).
On mips32r2 with uClibc simply running `gdb` with no arguments segfaults (even
`gdb --help` segfaults). I was able to obtain a stack trace by connecting to
`gdb-server` from my desktop.
On the device:
$ gdbserver 10.1.1.1:8001 gdb
On my desktop:
$ bin/mipsel-linux-gdb -ix
mipsel-gcw0-linux-uclibc/sysroot/usr/share/buildroot/gdbinit -ex="set sysroot
${PWD}/mipsel-gcw0-linux-uclibc/sysroot" -ex='target remote 10.1.1.2:8001'
../target/bin/gdb
Remote debugging using 10.1.1.2:8001
Reading symbols from
/home/gleb/repos/glebm/od_buildroot/output/gcw0/host/mipsel-gcw0-linux-uclibc/sysroot/lib/ld-uClibc.so.0...
0x77e28ed0 in _start () from
/home/gleb/repos/glebm/od_buildroot/output/gcw0/host/mipsel-gcw0-linux-uclibc/sysroot/lib/ld-uClibc.so.0
(gdb) bt
#0 0x77e28ed0 in _start () from
/home/gleb/repos/glebm/od_buildroot/output/gcw0/host/mipsel-gcw0-linux-uclibc/sysroot/lib/ld-uClibc.so.0
#1 0x in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) c
Continuing.
[Detaching after vfork from child process 618]
[New Thread 608.619]
Thread 2 "gdb worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 608.619]
#0 0x77b17ee0 in __gnu_cxx::__nothrow_wait_cv::wait (this=0xb5fd18, lock=...)
at ../../../../libstdc++-v3/src/c++11/compatibility-condvar.cc:74
#1 0x77b17ef0 in __gnu_cxx::__nothrow_wait_cv::wait (this=,
lock=...) at ../../../../libstdc++-v3/src/c++11/compatibility-condvar.cc:75
#2 0x77b17ef0 in __gnu_cxx::__nothrow_wait_cv::wait (this=,
lock=...) at ../../../../libstdc++-v3/src/c++11/compatibility-condvar.cc:75
... 60k more identical lines ...
#65232 0x77b44ef0 in __gnu_cxx::__nothrow_wait_cv::wait (this=,
lock=...) at ../../../../libstdc++-v3/src/c++11/compatibility-condvar.cc:75
#65233 0x77b44ef0 in __gnu_cxx::__nothrow_wait_cv::wait (this=,
lock=...) at ../../../../libstdc++-v3/src/c++11/compatibility-condvar.cc:75
#65234 0x008f1e00 in ?? ()
#65235 0x77b7b9a8 in std::execute_native_thread_routine (__p=0xb9dba0) at
../../../../../libstdc++-v3/src/c++11/thread.cc:82
#65236 0x77a3f3d8 in start_thread (arg=0x779700f0) at
libpthread/nptl/pthread_create.c:285
#65237 0x77980478 in __thread_start () at libc/sysdeps/linux/mips/clone.S:121
Backtrace stopped: frame did not save the PC
Possible culprit: 9e18a25331fa25c3907249fede65a02c6817b06e
(the function at compatibility-condvar.cc:75 was introduced in this commit).
---
gcc version information:
output/gcw0/host/bin/mipsel-linux-gcc -v
Using built-in specs.
COLLECT_GCC=/home/gleb/repos/glebm/od_buildroot/output/gcw0/host/bin/mipsel-linux-gcc.br_real
COLLECT_LTO_WRAPPER=/home/gleb/repos/glebm/od_buildroot/output/gcw0/host/bin/../libexec/gcc/mipsel-gcw0-linux-uclibc/12.2.0/lto-wrapper
Target: mipsel-gcw0-linux-uclibc
Configured with: ./configure
--prefix=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host
--sysconfdir=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host/etc
--enable-static --target=mipsel-gcw0-linux-uclibc
--with-sysroot=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host/mipsel-gcw0-linux-uclibc/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --enable-plugins --enable-lto
--with-gmp=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host
--with-mpc=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host
--with-mpfr=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host
--with-pkgversion='Buildroot 2022.08-1514-g9c33974d6c-dirty'
--with-bugurl=http://bugs.buildroot.net/ --without-zstd --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-libsanitizer
--enable-tls --enable-threads --without-isl --without-cloog
--with-arch=mips32r2 --with-abi=32 --with-nan=legacy --with-fp-32=xx
--enable-languages=c,c++
--with-build-time-tools=/home/gleb/repos/glebm/od_buildroot/output/gcw0/per-package/host-gcc-final/host/mipsel-gcw0-linux-uclibc/bin
--enable-shared --disable-libgomp --with-mips-plt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (Buildroot 2022.08-1514-g9c33974d6c-dirty)
[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511 Richard Biener changed: What|Removed |Added Blocks||85316 --- Comment #3 from Richard Biener --- There was a recent other PR with the very same issue. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106061 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-12-19 00:00:00 |2022-12-20 --- Comment #7 from Richard Biener --- Re-confirmed.
[Bug ipa/107300] [13 Regression] ICE: verify_ssa failed (error: virtual definition of statement not up to date)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-12-19 00:00:00 |2022-12-20 --- Comment #7 from Richard Biener --- Re-confirmed.
[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r13-1450-gd2a898666609452e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106249 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- No longer ICEs for me, so fixed.
[Bug c/108187] New: False positive -Wfree-nonheap-object on impossible path with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108187
Bug ID: 108187
Summary: False positive -Wfree-nonheap-object on impossible
path with -O1
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i.maximets at ovn dot org
Target Milestone: ---
Created attachment 54132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54132=edit
Reproducer
This might be the same issue as 98753, but I'm not sure.
We're getting the following error while trying to build Open vSwitch
with AF_XDP support with GCC:
```
In file included from lib/netdev-linux-private.h:30,
from lib/netdev-afxdp.c:19:
In function ‘dp_packet_delete’,
inlined from ‘dp_packet_delete’ at lib/dp-packet.h:246:1,
inlined from ‘dp_packet_batch_add__’ at lib/dp-packet.h:775:9,
inlined from ‘dp_packet_batch_add’ at lib/dp-packet.h:783:5,
inlined from ‘netdev_afxdp_rxq_recv’ at lib/netdev-afxdp.c:898:9:
lib/dp-packet.h:260:9: warning: ‘free’ called on pointer ‘*umem.xpool.array’
with nonzero offset [8, 2558044588346441168] [-Wfree-nonheap-object]
260 | free(b);
| ^~~
```
The simplified code flow is following:
```
packet = >xpool.array[index];
packet = >packet;
dp_packet_use_afxdp(packet, pkt, FRAME_SIZE - FRAME_HEADROOM,
OVS_XDP_HEADROOM);
--> dp_packet_init__(packet, allocated, DPBUF_AFXDP);
--> packet->source = source;
dp_packet_batch_add(batch, packet);
--> dp_packet_delete(packet);
--> if (b->source == DPBUF_AFXDP) {
free_afxdp_buf(b);
return;
}
dp_packet_uninit(b);
free(b);
```
The 'b->source' is always set unconditionally to DPBUF_AFXDP on that path,
so the free(b) cannot be reached, but compiler doesn't think so.
The issue is seen starting with -O1.
$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
Attached the file in question after -E. To reproduce run:
$ gcc -O1 -c netdev-afxdp.E.c
[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108139 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- fixed.
[Bug tree-optimization/108139] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1938-g87dd4c8c83768aaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108139 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0bdd2261c254f08b0f4437c156b79711d68c6e7f commit r13-4806-g0bdd2261c254f08b0f4437c156b79711d68c6e7f Author: Andrew MacLeod Date: Fri Dec 16 16:53:31 2022 -0500 Don't use PHI equivalences in range-on-entry. If there is only one argument to a PHI which is defined, an equivalency is created between the def and the argument. It is safe to consider the def equal to the argument, but it is dangerous to assume the argument is also equivalent to the def as there may be branches which change the range on the path to the PHI on that argument This patch avoid using that relation in range-on-entry calculations. PR tree-optimization/108139 gcc/ * gimple-range-cache.cc (ranger_cache::fill_block_cache): Do not use equivalences originating from PHIS. gcc/testsuite/ * gcc.dg/pr108139.c: New.
[Bug modula2/108121] Failing tests on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108121 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Martin Liška from comment #2) > > gm2.log: FAIL: gm2/pim/pass/TestLong4.mod, -g > > And this one fails due to UBSAN (signed integer overflow): > > /dev/shm/objdir/gcc/gm2 -B/dev/shm/objdir2/gcc > /home/marxin/Programming/gcc/gcc/testsuite/gm2/pim/pass/TestLong4.mod -c > /home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2expr.cc:4037:13: runtime > error: signed integer overflow: 1717986918 + 429496730 cannot be represented > in type 'int' > #0 0x4db49f6 in append_m2_digit > /home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2expr.cc:4037 > #1 0x4db52c0 in m2expr_interpret_m2_integer > /home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2expr.cc:4106 > #2 0x4da403c in m2decl_DetermineSizeOfConstant > /home/marxin/Programming/gcc/gcc/m2/gm2-gcc/m2decl.cc:296 > #3 0x4f8879e in GetConstLitType(unsigned int, unsigned int) > (/dev/shm/objdir2/gcc/cc1gm2+0x4f8879e) > #4 0x4f9d0e3 in SymbolTable_MakeConstLit > (/dev/shm/objdir2/gcc/cc1gm2+0x4f9d0e3) > #5 0x4f633a8 in P2SymBuild_BuildNumber > (/dev/shm/objdir2/gcc/cc1gm2+0x4f633a8) > #6 0x4fe4572 in Integer(unsigned int, unsigned int, unsigned int) > (/dev/shm/objdir2/gcc/cc1gm2+0x4fe4572) > #7 0x4fe5076 in Number(unsigned int, unsigned int, unsigned int) > (/dev/shm/objdir2/gcc/cc1gm2+0x4fe5076) > #8 0x4feea69 in Factor(unsigned int, unsigned int, unsigned int) > (/dev/shm/objdir2/gcc/cc1gm2+0x4feea69) The integer overflow is just one thing and could be easily worked around with performing the test_high = res_high + add_high; addition in append_m2_digit in unsigned and test_high = res_high + add_high; in append_digit in unsigned HOST_WIDE_INT type, like: test_high = (unsigned) res_high + add_high; or so. I must say I'm quite puzzled on the uses of INT_TYPE_SIZE in these functions though, I would have expected it would want instead HOST_BITS_PER_INT and HOST_BITS_PER_WIDE_INT, as that is number of bits on the host that can fit, and perhaps then depending on INT_TYPE_SIZE decide into which target type it fits. But say if HOST_BITS_PER_WIDE_INT is larger than INT_TYPE_SIZE (pretty much always), then I can't convince myself the routines will do the right thing. That said, I think the error on the test happens much later, LONGCARD on x86_64 seems to be unsigned 64-bit type, so 9223372036854775808 constant certainly fits there, but then: #4 0x01856de7 in make_int_cst (len=1, ext_len=1) at ../../gcc/tree.cc:2727 #5 0x0185268e in build_new_int_cst (type=, cst=...) at ../../gcc/tree.cc:1456 #6 0x01852c9a in force_fit_type (type=, cst=..., overflowable=1, overflowed=false) at ../../gcc/tree.cc:1570 #7 0x00f13238 in fold_convert_const_int_from_int (type=, arg1=) at ../../gcc/fold-const.cc:2045 #8 0x00f151ec in fold_convert_const (code=NOP_EXPR, type=, arg1=) at ../../gcc/fold-const.cc:2329 #9 0x00f12418 in const_unop (code=NOP_EXPR, type=, arg0=) at ../../gcc/fold-const.cc:1786 #10 0x00f32cc1 in fold_unary_loc (loc=0, code=NOP_EXPR, type=, op0=) at ../../gcc/fold-const.cc:9322 #11 0x00f482f6 in fold_build1_loc (loc=0, code=NOP_EXPR, type=, op0=) at ../../gcc/fold-const.cc:13767 #12 0x00dad298 in convert_to_integer_1 (type=, expr=, dofold=true) at ../../gcc/convert.cc:688 #13 0x00dae8d9 in convert_to_integer (type=, expr=) at ../../gcc/convert.cc:964 #14 0x00b91f78 in convert_loc (location=2147483650, type=, expr=) at ../../gcc/m2/gm2-lang.cc:735 #15 0x00bba6e3 in convert_and_check (loc=2147483650, type=, expr=) at ../../gcc/m2/gm2-gcc/m2convert.cc:316 #16 0x00bbae25 in m2convert_BuildConvert (location=2147483650, type=, value=, checkOverflow=1) at ../../gcc/m2/gm2-gcc/m2convert.cc:479 #17 0x00bfde58 in TryDeclareConst (tokenno=1975, sym=1003) at m2/gm2-compiler-boot/M2GCCDeclare.c:6875 #18 0x00c0613f in M2GCCDeclare_TryDeclareConstant (tokenno=1975, sym=1003) at m2/gm2-compiler-boot/M2GCCDeclare.c:11574 #19 0x00c3ae9c in FoldAssignment (tokenno=1172, q=56, r=17) at m2/gm2-compiler-boot/M2Range.c:1603 #20 0x00c40bbb in M2Range_FoldRangeCheck (tokenno=1172, q=56, r=17) at m2/gm2-compiler-boot/M2Range.c:4352 #21 0x00c0774c in FoldRange (tokenno=1172, quad=56, rangeno=17) at m2/gm2-compiler-boot/M2GenGCC.c:2225 #22 0x00c1555d in M2GenGCC_ResolveConstantExpressions (p=..., start=53, end=61) at m2/gm2-compiler-boot/M2GenGCC.c:8633 #23 0x00bff0b2 in DeclareTypesConstantsProceduresInRange (start=53, end=61) at m2/gm2-compiler-boot/M2GCCDeclare.c:7548 #24 0x00c44347 in M2Scope_ForeachScopeBlockDo (sb=0x3fd37b0, p=...) at
[Bug target/106012] rsqrtps and rcpps instructions generated even if -fno-reciprocal-math specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012 --- Comment #6 from vincenzo Innocente --- just to confirm that -Ofast -fno-reciprocal-math -mno-recip seems to inhibit all reciprocals... https://godbolt.org/z/f4bccb9GP
[Bug rust/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from ktkachov at gcc dot gnu.org --- > (In reply to Richard Biener from comment #17) >> Fixed(?) > > Yes on aarch64, thanks! Same on sparc.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 106149, which changed state. Bug 106149 Summary: [13 regression] g++.dg/warn/Warray-bounds-16.C had bogus errors after r13-1366-g1eef21ccfa5988 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106149 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug testsuite/106149] [13 regression] g++.dg/warn/Warray-bounds-16.C had bogus errors after r13-1366-g1eef21ccfa5988
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106149 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Richard Biener --- Fixed by reversion.
[Bug rust/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 --- Comment #18 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #17) > Fixed(?) Yes on aarch64, thanks!
[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106120 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug rust/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Richard Biener --- Fixed(?)
[Bug tree-optimization/105832] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #4 from Richard Biener --- Raising --param max-jump-thread-duplication-stmts from its default 15 to 17 fixes the issue. So the issue is slightly different accounting of sizes in the threading code and slightly different IL (though it is smaller). Quite possibly the bisection wasn't accurate.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 Richard Biener changed: What|Removed |Added Status|NEW |WAITING
[Bug rtl-optimization/105653] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105653 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Keywords||patch --- Comment #7 from Richard Biener --- Patch posted & approved.
[Bug c++/105511] [12/13 Regression] Spurious warning: "expected 'template' keyword..." when lt and gt compare over ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105511 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Richard Biener --- So indeed it works as documented, thus WONTFIX.
[Bug c++/105300] [10/11/12/13 Regression] segfault from static_assert with user-defined string suffix argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105300 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/105483] [10/11/12/13 Regression] injected-class-name and constructors diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105483 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug d/104749] [12/13 regression] stage1 d21 fails to link with GDC 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104749 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Richard Biener --- Fixed.
