[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764 --- Comment #5 from Richard Biener --- Hmm, that's not enough, the issue is this is detected as reduction at all.
[Bug target/111768] X86: -march=native does not support alder lake big.little cache infor correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768 --- Comment #6 from Arsen Arsenović --- this poses another problem too, though: should big and little cores ever differ in ISA support levels, building on big cores (which seems like a reasonable thing to do) with -march=native could lead to generating code incompatible with little cores. perhaps it'd be reasonable to always probe all cores (is that possible?) and pick a common subset?
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #11 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:701363d827d45d3e3601735fa42f95644fda8b64 commit r14-4583-g701363d827d45d3e3601735fa42f95644fda8b64 Author: Paul Thomas Date: Thu Oct 12 07:26:59 2023 +0100 Fortran: Set hidden string length for pointer components [PR67740]. 2023-10-11 Paul Thomas gcc/fortran PR fortran/67740 * trans-expr.cc (gfc_trans_pointer_assignment): Set the hidden string length component for pointer assignment to character pointer components. gcc/testsuite/ PR fortran/67740 * gfortran.dg/pr67740.f90: New test
[Bug target/111778] PowerPC constant code change uses an undefined shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778 --- Comment #2 from Jiu Fu Guo --- Thanks so much for reporting this issue, and thanks for tracing down it! For the code, if 'lz' is 0, it is correct to return false.
[Bug target/106271] Bootstrap on RISC-V on Ubuntu 22.04 LTS: bits/libc-header-start.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271 --- Comment #9 from Matthias Klose --- yes, that's one which could be also backported. Let me submit the other bits upstream as well.
[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #10 from Kewen Lin ---
(In reply to Carl Love from comment #9)
> I made a copy of rs6000-overload.def and then with a series of emacs macros
> converted the list of builtins to a script to grep for the builtins in the
> test directory. Specifically from rs6000-overload.def:
>
> [BCDADD, __builtin_bcdadd, __builtin_vec_bcdadd]
> vsq __builtin_vec_bcdadd (vsq, vsq, const int);
> BCDADD_V1TI
> vuc __builtin_vec_bcdadd (vuc, vuc, const int);
> BCDADD_V16QI
>
> [BCDADD_EQ, __builtin_bcdadd_eq, __builtin_vec_bcdadd_eq]
> signed int __builtin_vec_bcdadd_eq (vsq, vsq, const int);
> BCDADD_EQ_V1TI
> signed int __builtin_vec_bcdadd_eq (vuc, vuc, const int);
> BCDADD_EQ_V16QI
>
>
>
> Was converted to the bash script:
>
> rm -f ../test1_not_found
>
> NOT_FOUND='0 0 0'
> check_name () {
> str1=$(grep -r $1 * | wc)
>
> # echo " output of command: $str1"
>
> if [[ "$str1" == *"$NOT_FOUND"* ]]; then
> echo "$1 not found" >> ../test1_not_found
> fi
> }
>
> check_name "__builtin_bcdadd" "__builtin_vec_bcdadd"
>
> check_name "__builtin_bcdadd_eq" "__builtin_vec_bcdadd_eq"
>
>
>
> The script is passed the user built-in name ($str1) and the internal
> built-in name ($str2). I ran the script in directory
> gcc/testsuite/gcc.target/powerpc
> and it identified two tests ($str1) as not showing up in a test file. The
> tests were: __builtin_bcdsub_ge and __builtin_bcdsub_le.
>
> I figure if the first builtin name has a test associated with it that should
> be sufficient. I will create a patch to add testcases for the two missing
> builtin-names.
>
> I did add to the script to see how many definitions have a test for the
> built-in name $1 but not the built-in name $2 doesn't show up in a test
> file. My script identified 86 of these cases. Not sure that we really need
> to add test cases for the internal builtin name ($str). Thoughts?
Thanks for tracking this! As you said, I think checking the name $1 is
sufficient since only those are visible for users. btw, since this is closed,
let us discuss it on the internal issue further. :)
[Bug c++/111771] Incorrect "is used uninitialized" warning, as if zero-initialization didn't propagate through user-provided default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111771 --- Comment #2 from Egor --- Before calling A's constructor, it will zero `x` anyway. I was also surprised when I learned this yesterday, but it's what the standard says. 1. `()` performs value-initialization on B: http://eel.is/c++draft/dcl.dcl#dcl.init.general-16.4 2. Since B's ctor is not user-provided, that resolves to zero-initialization followed by default-initialization: http://eel.is/c++draft/dcl.dcl#dcl.init.general-9.1.2 3. Zero-initialization of B propagates to A, then propagates to `x` and zeroes it, regardless of A having a user-provided constructor or not: http://eel.is/c++draft/dcl.dcl#dcl.init.general-6.2 4. Lastly default-initialization of B calls B's constructor and in turn calls A's constructor.
[Bug testsuite/111427] [14 regression] gfortran.dg/vect/pr60510.f fails after r14-3999-g3c834d85f2ec42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Kewen Lin --- This failure should be gone as Vladimir reverted the commit exposing this, the fix on uninit var has been also committed.
[Bug target/111367] Error: operand out of range (0x1391c is not between 0xffffffffffff8000 and 0x7fff)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367 --- Comment #14 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:530babc2058be5f2b06b1541384e7b730c368b93 commit r14-4582-g530babc2058be5f2b06b1541384e7b730c368b93 Author: Kewen Lin Date: Thu Oct 12 00:05:03 2023 -0500 rs6000: Make 32 bit stack_protect support prefixed insn [PR111367] As PR111367 shows, with prefixed insn supported, some of checkings consider it's able to leverage prefixed insn for stack protect related load/store, but since we don't actually change the emitted assembly for 32 bit, it can cause the assembler error as exposed. Mike's commit r10-4547-gce6a6c007e5a98 has already handled the 64 bit case (DImode), this patch is to treat the 32 bit case (SImode) by making use of mode iterator P and ptrload attribute iterator, also fixes the constraints to match the emitted operand formats. PR target/111367 gcc/ChangeLog: * config/rs6000/rs6000.md (stack_protect_setsi): Support prefixed instruction emission and incorporate to stack_protect_set. (stack_protect_setdi): Rename to ... (stack_protect_set): ... this, adjust constraint. (stack_protect_testsi): Support prefixed instruction emission and incorporate to stack_protect_test. (stack_protect_testdi): Rename to ... (stack_protect_test): ... this, adjust constraint. gcc/testsuite/ChangeLog: * g++.target/powerpc/pr111367.C: New test.
[Bug testsuite/111427] [14 regression] gfortran.dg/vect/pr60510.f fails after r14-3999-g3c834d85f2ec42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111427 --- Comment #4 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:610b845a426e26fa86724e5c9d6f74c7a4baf741 commit r14-4581-g610b845a426e26fa86724e5c9d6f74c7a4baf741 Author: Kewen Lin Date: Thu Oct 12 00:04:58 2023 -0500 testsuite: Avoid uninit var in pr60510.f [PR111427] The uninitialized variable a in pr60510.f can cause some random failures as exposed in PR111427. This patch is to make it initialized accordingly. PR testsuite/111427 gcc/testsuite/ChangeLog: * gfortran.dg/vect/pr60510.f (test): Init variable a.
[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 --- Comment #19 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:e1e127de18dbee47b88fa0ce74a1c7f4d658dc68 commit r14-4571-ge1e127de18dbee47b88fa0ce74a1c7f4d658dc68 Author: Zhang, Jun Date: Fri Sep 22 23:56:37 2023 +0800 x86: set spincount 1 for x86 hybrid platform By test, we find in hybrid platform spincount 1 is better. Use '-march=native -Ofast -funroll-loops -flto', results as follows: spec2017 speed RPL ADL 657.xz_s 0.00% 0.50% 603.bwaves_s 10.90% 26.20% 607.cactuBSSN_s 5.50% 72.50% 619.lbm_s2.40% 2.50% 621.wrf_s-7.70% 2.40% 627.cam4_s 0.50% 0.70% 628.pop2_s 48.20% 153.00% 638.imagick_s-0.10% 0.20% 644.nab_s2.30% 1.40% 649.fotonik3d_s 8.00% 13.80% 654.roms_s 1.20% 1.10% Geomean-int 0.00% 0.50% Geomean-fp 6.30% 21.10% Geomean-all 5.70% 19.10% omp2012 RPL ADL 350.md -1.81% -1.75% 351.bwaves 7.72% 12.50% 352.nab 14.63% 19.71% 357.bt331-0.20% 1.77% 358.botsalgn 0.00% 0.00% 359.botsspar 0.00% 0.65% 360.ilbdc0.00% 0.25% 362.fma3d2.66% -0.51% 363.swim 10.44% 0.00% 367.imagick 0.00% 0.12% 370.mgrid331 2.49% 25.56% 371.applu331 1.06% 4.22% 372.smithwa 0.74% 3.34% 376.kdtree 10.67% 16.03% GEOMEAN 3.34% 5.53% include/ChangeLog: PR target/109812 * spincount.h: New file. libgomp/ChangeLog: * env.c (initialize_env): Use do_adjust_default_spincount. * config/linux/x86/spincount.h: New file.
[Bug target/111778] PowerPC constant code change uses an undefined shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778 --- Comment #1 from Andrew Pinski --- On the date. It is the author date vs commit date. You can see that here https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=8f1a70a4fbcc6441c70da60d4ef6db1e5635e18a .
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #20 from Rui Ueyama --- Last time I tried, mold-produced binaries crash on a real POWER10 machine, but I couldn't debug it due to some issue (gdb's issue or something but I don't remember exactly what that was.) Let me try again when I have time.
[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit pointer size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147 --- Comment #9 from Peter Bergner --- (In reply to CVS Commits from comment #8) > The master branch has been updated by Vladimir Makarov > : > > https://gcc.gnu.org/g:51ca05031959d3accffe873e87d4bc4fbd22e9e9 > > commit r12-3881-g51ca05031959d3accffe873e87d4bc4fbd22e9e9 > Author: Vladimir N. Makarov > Date: Fri Sep 24 10:06:45 2021 -0400 > > Make profitability calculation of RA conflict presentations independent > of host compiler type sizes. [PR102147] > > gcc/ChangeLog: > > 2021-09-24 Vladimir Makarov > > PR rtl-optimization/102147 > * ira-build.c (ira_conflict_vector_profitable_p): Make > profitability calculation independent of host compiler pointer > and > IRA_INT_BITS sizes. Can we mark this as RESOLVED / FIXED now?
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #19 from Peter Bergner --- (In reply to Rui Ueyama from comment #11) > I'll try to add a POWER10 support to mold using Qemu. I noticed some Power10 mold code was committed in March. Does that mean this is "fixed" in mold now? If not, the Power10 GCC farm system is now available for use. The Power10 system is: gcc120
[Bug target/111778] PowerPC constant code change uses an undefined shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778 Michael Meissner changed: What|Removed |Added Severity|normal |major Priority|P3 |P2 CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||guojiufu at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org Build||powerpc64le-unknown-linux-g ||nu Target||powerpc64le-unknown-linux-g ||nu Host||x86_64-unknown-linux-gnu
[Bug target/111778] New: PowerPC constant code change uses an undefined shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778
Bug ID: 111778
Summary: PowerPC constant code change uses an undefined shift
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was building a cross compiler to PowerPC on my x86_86 workstation with the
latest version of GCC on October 11th. I could not build the compiler on the
x86_64 system as it died in building libgcc. I looked into it, and I
discovered the compiler was recursing until it ran out of stack space. If I
build a native compiler with the same sources on a PowerPC system, it builds
fine.
I traced this down to a change made around October 10th:
commit 8f1a70a4fbcc6441c70da60d4ef6db1e5635e18a (HEAD)
Author: Jiufu Guo
Date: Tue Jan 10 20:52:33 2023 +0800
rs6000: build constant via li/lis;rldicl/rldicr
If a constant is possible left/right cleaned on a rotated value from
a negative value of "li/lis". Then, using "li/lis ; rldicl/rldicr"
to build the constant.
gcc/ChangeLog:
* config/rs6000/rs6000.cc (can_be_built_by_li_lis_and_rldicl): New
function.
(can_be_built_by_li_lis_and_rldicr): New function.
(rs6000_emit_set_long_const): Call
can_be_built_by_li_lis_and_rldicr and
can_be_built_by_li_lis_and_rldicl.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/const-build.c: Add more tests.
In particular, the code is:
static bool
can_be_built_by_li_lis_and_rldicl (HOST_WIDE_INT c, int *shift,
HOST_WIDE_INT *mask)
{
/* Leading zeros may be cleaned by rldicl with a mask. Change leading zeros
to ones and then recheck it. */
int lz = clz_hwi (c);
HOST_WIDE_INT unmask_c
= c | (HOST_WIDE_INT_M1U << (HOST_BITS_PER_WIDE_INT - lz));
int n;
if (can_be_rotated_to_lowbits (~unmask_c, 15, &n)
|| can_be_rotated_to_negative_lis (unmask_c, &n))
{
*mask = HOST_WIDE_INT_M1U >> lz;
*shift = n == 0 ? 0 : HOST_BITS_PER_WIDE_INT - n;
return true;
}
return false;
}
In particular, if lz is 0 due to the constant having the highest bit set, the
-1 shift to set the mask in unmask_c would do a shift left by 64.
Different machines interpret num << shift differently if shift is at least the
number of bits in num's representation. It is explicitly undefined behavior in
the C/C++ langauges.
In particular (-1 << 64) on an x86_64 produces -1 and (-1 << 64) on a 64-bit
PowerPC produces 0.
If I add a test for lz being 0 and returning false, the compiler builds fine.
One other note is the ChangeLog date is not correct for Jiufu Guo's changes
that include this change. The several changes that were submitted list dates
of:
Tue Jan 10 21:40:48 2023 +0800
Tue Jan 10 20:52:33 2023 +0800
Thu Jun 15 21:11:53 2023 +0800
Thu Aug 24 09:08:34 2023 +0800
[Bug tree-optimization/94889] Negate function not getting optimised to bitwise not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94889 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |13.0 --- Comment #7 from Andrew Pinski --- final value replacement: x_11 = PHI with expr: ~x_4(D) final stmt: x_11 = ~x_4(D); All fixed in GCC 13 for all 3 testcases even.
[Bug rtl-optimization/26190] combine misses some distributivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Known to work||10.1.0 Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #9 from Andrew Pinski --- Fixed in GCC 10.1.0. Part of it was fixed with r6-3841-g84ff66b884e9 . The other part which fixed this was improving EVRP.
[Bug rtl-optimization/18395] [meta-bug] combine needs to be templatized like a peepholer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18395 Bug 18395 depends on bug 26190, which changed state. Bug 26190 Summary: combine misses some distributivity https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26190 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/88808] bitwise operators on AVX512 masks fail to use the new mask instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88808 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Fixed as mentioned.
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-12 Ever confirmed|0 |1 --- Comment #6 from Jeffrey A. Law --- I would hazard a guess that Mary doesn't have a bugzilla account. I'll drop her a direct email.
[no subject]
บริการสินเชื่ออนุมัติง่ายทันใจ สำหรับท่านเจ้าของกิจการที่ต้องการทุนไปหมุนเวียนในธุรกิจและขยายธุรกิจของท่าน ⏩ เอกสารไม่ยุ่งยาก อนุมัติไว วงเงินสูง 5 ล้านบาท ⏩ มีที่จัดตั้งกิจการ บริษัท หจก.ชัดเจนสามารถตรวจสอบได้ ⏩ ไม่ต้องใช้หลักทรัพย์ ⏩ ติดแบล็คลิสเครดิตบูโรกู้ได้จริง 100 % ⏰ ใช้เวลาแค่ 30 นาที อนุมัติรับเงินทันที โทร : 0961958726 (คุณ สรวิชญ์) 🚗 เราไปบริการทำสินเชื่อ ไม่เสียค่าใช้จ่ายใดๆทั้งสิ้น 🤝: สอบถามฟรีพนักงานสุภาพครับ เก็บข้อมูลนี้ใว้ เผื่อวันนึงท่านอาจจำเป็นต้องใช้ 🙏🏻🙏🏻
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 --- Comment #5 from Andrew Pinski --- (In reply to seurer from comment #3) > Note: "mary.benn...@embecosm.com" does not work for a CC address and I > don't see another Mary Bennett. I added Jeff to the CC who committed the patch upon Mary so hopefully Jeff can help here.
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 --- Comment #4 from seurer at gcc dot gnu.org --- Oops, wrong system. On the failing one it shows: makeinfo (GNU texinfo) 5.1
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 seurer at gcc dot gnu.org changed: What|Removed |Added Build||powerpc64-linux-gnu Target||powerpc64-linux-gnu Host||powerpc64-linux-gnu --- Comment #3 from seurer at gcc dot gnu.org --- makeinfo --version shows texi2any (GNU texinfo) 6.7 Note: "mary.benn...@embecosm.com" does not work for a CC address and I don't see another Mary Bennett.
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 --- Comment #2 from Andrew Pinski --- We currently require texinfo 4.7: https://gcc.gnu.org/install/prerequisites.html
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 --- Comment #1 from Andrew Pinski --- Waht version of makeinfo/texinfo is installed there?
[Bug middle-end/111777] [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 Andrew Pinski changed: What|Removed |Added Keywords||build, documentation Component|bootstrap |middle-end Target Milestone|--- |14.0
[Bug bootstrap/111777] New: [14 regression] build breaks after r14-4558-g400efdddf3d849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111777 Bug ID: 111777 Summary: [14 regression] build breaks after r14-4558-g400efdddf3d849 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:400efdddf3d8499d7c7969d26bedb537a625c070, r14-4558-g400efdddf3d849 This breaks the build on some of our older (power 7/8) big endian systems. make . . . if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --split-size=500 --no-split -I . -I /home/seurer/gcc/git/gcc-test/gcc/doc \ -I /home/seurer/gcc/git/gcc-test/gcc/doc/include -o doc/gcc.info /home/seurer/gcc/git/gcc-test/gcc/doc/gcc.texi; \ fi /home/seurer/gcc/git/gcc-test/gcc/doc/extend.texi:21708: warning: node next `RISC-V Vector Intrinsics' in menu `CORE-V Built-in Functions' and in sectioning `RX Built-in Functions' differ /home/seurer/gcc/git/gcc-test/gcc/doc/extend.texi:21716: warning: node `RX Built-in Functions' is next for `CORE-V Built-in Functions' in menu but not in sectioning /home/seurer/gcc/git/gcc-test/gcc/doc/extend.texi:21716: warning: node `RISC-V Vector Intrinsics' is prev for `CORE-V Built-in Functions' in menu but not in sectioning /home/seurer/gcc/git/gcc-test/gcc/doc/extend.texi:21716: warning: node up `CORE-V Built-in Functions' in menu `Target Builtins' and in sectioning `RISC-V Vector Intrinsics' differ /home/seurer/gcc/git/gcc-test/gcc/doc/extend.texi:21708: node `RISC-V Vector Intrinsics' lacks menu item for `CORE-V Built-in Functions' despite being its Up target /home/seurer/gcc/git/gcc-test/gcc/doc/extend.texi:21795: warning: node prev `RX Built-in Functions' in menu `CORE-V Built-in Functions' and in sectioning `RISC-V Vector Intrinsics' differ make[2]: *** [doc/gcc.info] Error 1 commit 400efdddf3d8499d7c7969d26bedb537a625c070 Author: Mary Bennett Date: Wed Oct 11 07:39:41 2023 -0600 [PATCH v4 1/2] RISC-V: Add support for XCVmac extension in CV32E40P Spec: github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #8 from Iain Buclaw --- Looking at C++ FE, I see they construct the string literal using build_string (4, "foo") because I can see the terminating 0 in the pretty-printed string. --- unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7743b5e8 precision:8 min max pointer_to_this > type_6 BLK size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7717d0a8 domain type_6 DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7717de70 precision:64 min max > pointer_to_this > readonly constant static "hello world\000"> --- I see in the olden days when D sat outside of GCC, this is what was done too. https://github.com/D-Programming-GDC/gdc/commit/b9d36fc9d71ec4122d1c986599d87c6cb91ca55c This might have been accidentally removed by another contributor in an apparent drive-by search and replace of a specific pattern. https://github.com/D-Programming-GDC/gdc/commit/f8a05f41cb756ef7ed2b1d8b1d33eb8f815421a5
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 Andrew Macleod changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Andrew Macleod --- now fixed on gcc 13 too.
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 --- Comment #10 from CVS Commits --- The releases/gcc-13 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:f0efc4b25cba1bd35b08b7dfbab0f8fc81b55c66 commit r13-7945-gf0efc4b25cba1bd35b08b7dfbab0f8fc81b55c66 Author: Andrew MacLeod Date: Mon Oct 9 13:40:15 2023 -0400 Ensure float equivalences include + and - zero. A floating point equivalence may not properly reflect both signs of zero, so be pessimsitic and ensure both signs are included. PR tree-optimization/111694 gcc/ * gimple-range-cache.cc (ranger_cache::fill_block_cache): Adjust equivalence range. * value-relation.cc (adjust_equivalence_range): New. * value-relation.h (adjust_equivalence_range): New prototype. gcc/testsuite/ * gcc.dg/pr111694.c: New.
[Bug modula2/111756] Re-building all-gcc after source changes fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-10-11 Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Many thanks for the report. I'll add -M and friends (-MM, -MF, etc) support to gm2 and cc1gm2.
[Bug c++/111776] ICE on delete expression with multiple viable destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111776 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-10-11 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. even g++9 ICEs. g++8 gives errors.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #7 from Iain Buclaw ---
(In reply to David Malcolm from comment #5)
> Is D correctly building that string_cst? Are D strings 0-terminated?
Yes, D strings are 0-terminated.
The way I've done it is, the string is constructed using
build_string(3, "foo")
but the TREE_TYPE is set to `char[4]` so that the terminating 0 is considered.
I'm sure it's like this because either GCC has a tendency to emit strings
side-by-side without the 0 so strlen("foo") could return 20, or there's an
optimization pass for strlen() that would otherwise evaluate strlen("foo") into
2 if I set the type of the literal as `char[3]`.
[Bug target/111774] boringssl performance gap between clang and gcc for x25519 operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111774 --- Comment #3 from cpu --- > What happens if you enable the above for GCC too? That appears to have helped, but not closed the gap: ``` Did 39600 Ed25519 key generation operations in 1001716us (39532.2 ops/sec) Did 41000 Ed25519 signing operations in 1006641us (40729.5 ops/sec) Did 32000 Ed25519 verify operations in 1020079us (31370.1 ops/sec) Did 43000 Curve25519 base-point multiplication operations in 1023075us (42030.2 ops/sec) Did 39000 Curve25519 arbitrary point multiplication operations in 1008147us (38684.8 ops/sec) ```
[Bug c++/111776] New: ICE on delete expression with multiple viable destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111776
Bug ID: 111776
Summary: ICE on delete expression with multiple viable
destroying operator delete
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leni536 at gmail dot com
Target Milestone: ---
version: gcc 13.2.0
flags: -std=c++20 -O2 -pedantic-errors
```
#include
struct B {
void operator delete(B* ptr, std::destroying_delete_t);
};
struct D : B {
void operator delete(D* ptr, std::destroying_delete_t);
using B::operator delete;
};
void bar(D* ptr) {
delete ptr;
}
```
internal compiler error: in build_op_delete_call, at cp/call.cc:7914
13 | delete ptr;
|^~~
0x1ce7bde internal_error(char const*, ...)
???:0
0x7290fc fancy_abort(char const*, int, char const*)
???:0
0x7eb68c build_delete(unsigned int, tree_node*, tree_node*,
special_function_kind, int, int, int)
???:0
0x7d3757 delete_sanity(unsigned int, tree_node*, tree_node*, bool, int, int)
???:0
0x89fd5b c_parse_file()
???:0
0x98c5d9 c_common_parse_file()
???:0
https://godbolt.org/z/8rh7h7EWz
I'm not entirely sure what should actually happen here. I didn't find a
disambiguating rule at https://timsong-cpp.github.io/cppwp/n4868/expr.delete#10
.
[Bug target/111774] boringssl performance gap between clang and gcc for x25519 operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111774
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Hmm:
> #if defined(__clang__) // materialize for vectorization, 6% speedup
> __asm__("" : "+m" (t_bytes) : /*no inputs*/);
> #endif
>
>
> What target is this for? What processor too?
What happens if you enable the above for GCC too?
[Bug target/111774] boringssl performance gap between clang and gcc for x25519 operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111774
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Component|c |target
Last reconfirmed||2023-10-11
Keywords||missed-optimization
--- Comment #1 from Andrew Pinski ---
Hmm:
#if defined(__clang__) // materialize for vectorization, 6% speedup
__asm__("" : "+m" (t_bytes) : /*no inputs*/);
#endif
What target is this for? What processor too?
[Bug tree-optimization/108697] constructing a path-range-query is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697 Andrew Macleod changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Macleod --- fixed.
[Bug fortran/104351] ICE in gfc_generate_initializer, at fortran/expr.cc:5140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104351 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 #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-October/059812.html
[Bug middle-end/111775] New: -Wstrict-flex-arrays missing diagnostics with unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111775
Bug ID: 111775
Summary: -Wstrict-flex-arrays missing diagnostics with unions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: crrodriguez at opensuse dot org
Target Milestone: ---
following code is not diagnosed
#include
#include
#include
struct foo {
int dum;
union {
/* or [1] */
char a[0];
wchar_t b[0];
} fn;
};
int main(void)
{
struct foo *f = malloc(sizeof(*f));
/* or really any use of the union does not matter */
printf("%p", f->fn.b);
free(f);
return 0;
}
compile options
-Wall -fstrict-flex-arrays -Werror=strict-flex-arrays -O2
This test is a silly mockup of real widespread code, which goes undiagnosed
until test suites run and/or is built with ubsan.
[Bug c/111774] New: boringssl performance gap between clang and gcc for x25519 operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111774 Bug ID: 111774 Summary: boringssl performance gap between clang and gcc for x25519 operations Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel at binaryparadox dot net Target Milestone: --- Hi folks, I've been bisecting a performance regression for x25519 cryptographic operations with BoringSSL (https://boringssl.googlesource.com/boringssl) that causes builds with gcc (tested w/ 13.2.0) to perform significantly worse than builds with clang (tested w/ clang 11.1.0). I've identified the regression is in this commit: https://github.com/google/boringssl/commit/d605df5b6f8462c1f3005da82d718ec067f46b70 Building the project with gcc prior to this commit (Linux 6.1.55, gcc 13.2.0, 12th Gen Intel Core i7-1280P) shows the following numbers in the boringssl performance tests: Did 90900 Ed25519 key generation operations in 1006408us (90321.2 ops/sec) Did 94000 Ed25519 signing operations in 1002192us (93794.4 ops/sec) Did 33000 Ed25519 verify operations in 1029750us (32046.6 ops/sec) Did 103000 Curve25519 base-point multiplication operations in 1005442us (102442.5 ops/sec) Did 39000 Curve25519 arbitrary point multiplication operations in 1010017us (38613.2 ops/sec) Building the project with gcc at the identified regression commit produces worse numbers for the same benchmarks: Did 33744 Ed25519 key generation operations in 1006475us (33526.9 ops/sec) Did 34000 Ed25519 signing operations in 1011973us (33597.7 ops/sec) Did 32000 Ed25519 verify operations in 1032193us (31002.0 ops/sec) Did 36000 Curve25519 base-point multiplication operations in 1021745us (35233.8 ops/sec) Did 39000 Curve25519 arbitrary point multiplication operations in 1020887us (38202.1 ops/sec) Running the same tests prior to the problematic commit but using clang 11.1.0 produces these numbers: Did 80132 Ed25519 key generation operations in 1004593us (79765.6 ops/sec) Did 81000 Ed25519 signing operations in 1003061us (80752.8 ops/sec) Did 28000 Ed25519 verify operations in 1010878us (27698.7 ops/sec) Did 87000 Curve25519 base-point multiplication operations in 1005378us (86534.6 ops/sec) Did 38000 Curve25519 arbitrary point multiplication operations in 1004032us (37847.4 ops/sec) And doing the same with the problematic commit and clang 11.1.0 shows: Did 83739 Ed25519 key generation operations in 1007756us (83094.5 ops/sec) Did 88000 Ed25519 signing operations in 1010131us (87117.4 ops/sec) Did 31000 Ed25519 verify operations in 1013649us (30582.6 ops/sec) Did 94000 Curve25519 base-point multiplication operations in 1008822us (93178.0 ops/sec) Did 39000 Curve25519 arbitrary point multiplication operations in 1020461us (38218.0 ops/sec) You can see with the reported numbers that while the clang build is a little bit slower after the problematic commit, the GCC build is much slower, suggesting something specific to GCC is causing the slow down. I'm not confident in my ability to dissect the underlying cause, but suspect that GCC's handling of the new precomputed table representation is not as efficient as it could be relative to clang. I'm hopeful that with clear reproduction steps someone more familiar would be able to make progress. I've already opened a bug with the BoringSSL project: https://bugs.chromium.org/p/boringssl/issues/detail?id=655 Here are the reproduction steps: 1. Check out https://github.com/google/boringssl/commit/d605df5b6f8462c1f3005da82d718ec067f46b70 2. Configure and build the project **with GCC**: ``` CFLAGS="-Wno-error=stringop-overflow" CC= CXX= cmake -DCMAKE_BUILD_TYPE=Release -B build-release-gcc make -C build-release-gcc ``` 3. Run the `bssl speed` tool, filtering for `25519`: ``` build-release-gcc/tool/bssl speed -filter 25519 ``` 4. Observe slower results. ``` 5. Check out https://github.com/google/boringssl/commit/4a0393fcf37d7dbd090a5bb2293601a9ec7605da - the parent commit to d605df5b6f8462c1f3005da82d718ec067f46b70 6. Repeat the process described above. 7. Observe faster results. The same process can be undertaken with clang by substituting the `cmake` step with: CC=clang CXX=clang++ cmake -DCMAKE_BUILD_TYPE=Release -B build-release-clang make -C build-release-clang Thank you!
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #6 from David Malcolm --- Oops; the above got truncated; the string_cst prints as follows in gdb (gdb) pt string_cst unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea772930 precision:8 min max pointer_to_this > SI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea78a150 domain DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea672150 precision:64 min max > pointer_to_this > constant "foo">
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #5 from David Malcolm --- It's complaining about the read from the string literal. If I change the string in the reproducer from "hello world" to "foo", I see: (gdb) pt string_cst unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea772930 precision:8 min max pointer_to_this > SI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea78a150 domain DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffea672150 precision:64 min max > pointer_to_this string.length) (gdb) p string_cst->string.length $36 = 3 The analyzer is using this for determining the validly accessible size of the string, which it determines is 3 bytes: (gdb) call valid_bits.dump(true) bytes 0-2 whereas the read is of 4 bytes: (gdb) call actual_bits.dump(true) bytes 0-3 Is D correctly building that string_cst? Are D strings 0-terminated?
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 --- Comment #4 from David Malcolm --- (In reply to David Malcolm from comment #3) > Thanks; that reproducer works for me. ...or rather, demonstrates the ICE in a way that I can see in the debugger.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-10-11 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from David Malcolm --- Thanks; that reproducer works for me.
[Bug c++/111771] Incorrect "is used uninitialized" warning, as if zero-initialization didn't propagate through user-provided default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111771 --- Comment #1 from Andrew Pinski --- Did you miss that the implicit B constructor will just call A's constructor ?
[Bug c/111769] Annotate function definitions and calls to facilitate link-time checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769 --- Comment #2 from Andrew Pinski --- IIRC there was a bug about this specific thing which was closed as fixed with the use of LTO ...
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #7 from Andrew Pinski --- Fixed.
[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e8d418df3dc609f27487deece796d4aa69004b8c commit r14-4561-ge8d418df3dc609f27487deece796d4aa69004b8c Author: Andrew Pinski Date: Tue Oct 10 12:45:56 2023 -0700 MATCH: [PR111282] Simplify `a & (b ^ ~a)` to `a & b` While `a & (b ^ ~a)` is optimized to `a & b` on the rtl level, it is always good to optimize this at the gimple level and allows us to match a few extra things including where a is a comparison. Note I had to update/change the testcase and-1.c to avoid matching this case as we can match -2 and 1 as bitwise inversions. PR tree-optimization/111282 gcc/ChangeLog: * match.pd (`a & ~(a ^ b)`, `a & (a == b)`, `a & ((~a) ^ b)`): New patterns. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/and-1.c: Update testcase to avoid matching `~1 & (a ^ 1)` simplification. * gcc.dg/tree-ssa/bitops-6.c: New test.
[Bug analyzer/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #2 from Iain Buclaw ---
(In reply to David Malcolm from comment #1)
> Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc:
> ./gdc -B. -S -fanalyzer oob.d
> I get:
> d21: error: cannot find source code for runtime library file 'object.d'
>
> Possibly a silly question, but what am I doing wrong?
The library sources aren't in any paths that the compiler looks for. It should
work without any explicit `-I` if the target libraries were installed.
This alternative reproducer should get you off the ground though.
---
mkdir gcc;
echo "module gcc.builtins;" > gcc/builtins.d
cat > oob.d << EOF
module object;
import gcc.builtins;
void main()
{
char[5] arr;
__builtin_strcpy(arr.ptr, "hello world");
}
EOF
./gdc -B. -S -fanalyzer oob.d
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #10 from Mikael Morin --- (In reply to Mikael Morin from comment #8) > (...) that is it was using too loops in a row in some cases. > ... *two* loops in a row ... (In reply to Tamar Christina from comment #9) > > Thanks Mikael! > > That's already plenty of help! I can try to debug further after I finish my > current patches. Would it be ok if I ask questions when I do? Yes, of course. I forgot to precise that the patch above supports only calls without any optional args. Allowing non-DIM arguments should work, as the code supporting them is already there for the scalar case. For the DIM argument, it's a bit more work. I'm not sure, but maybe the scalarizer support for reductions (SUM or PRODUCT with DIM arg) can be used to support it.
[Bug c++/111773] Inconsistent optimization of replaced operator new()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111773 --- Comment #1 from Andrew Pinski --- I think both of these are valid things to do according to the standard and the requirements of operator new.
[Bug c++/111773] New: Inconsistent optimization of replaced operator new()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111773
Bug ID: 111773
Summary: Inconsistent optimization of replaced operator new()
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlad at solidsands dot nl
Target Milestone: ---
#include
#include
#include
int a[10];
void* operator new(std::size_t) {
return a;
}
int main() {
int* p = static_cast(::operator new(sizeof(int)));
std::ptrdiff_t x = a - p;
printf("%ld %d", x, x == 0);
return 0;
}
Here, GCC with -O1 optimizes 'x' to 0 and 'x == 0' to false at the same time.
Compiler explorer link: https://godbolt.org/z/4Y3eeY56r
---
Also, possibly related:
#include
void* operator new(std::size_t sz)
{
throw std::bad_alloc{};
}
int main()
{
int* p1 = static_cast(::operator new(sizeof(int)));
return 10;
}
Here, again with -O1, terminate is not called, and the program returned
successfully. However, the program returned 0 instead of 10.
Compiler explorer link: https://godbolt.org/z/9oczTzP7s
[Bug regression/111709] [13/14 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709 --- Comment #11 from John David Anglin --- This is proving difficult to bisect due to _Floatn issues. I know commit b85e79dce149df68b92ef63ca2a40ff1dfa61396 is good and commit b939a5cc4143908ddda4b85a848c313136ff6e0c is bad. The following glibc change breaks gcc build when BASE-VER changes to 13. https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3e5760fcb48528d48deeb60cb885a97bb731160c If I change __GNUC_PREREQ to 13, 1, I hit errors like: In file included from /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl ude/cmath:45, from /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl ude/complex:44, from ../../../../../gcc/libstdc++-v3/src/c++98/complex_io.cc:25 : /usr/include/math.h:1395:19: error: redefinition of ‘struct __iseqsig_type’ 1395 | template<> struct __iseqsig_type<_Float32> | ^~~~ /usr/include/math.h:1366:19: note: previous definition of ‘struct __iseqsig_type ’ 1366 | template<> struct __iseqsig_type There are a lot of VRP changes for floats in the range that I haven't been able to bisect. | ^
[Bug rtl-optimization/111772] New: ICE on gfortran.dg/transpose_conjg_1.f90 in regrename.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111772
Bug ID: 111772
Summary: ICE on gfortran.dg/transpose_conjg_1.f90 in
regrename.cc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fkastl at suse dot cz
CC: jamborm at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux
Target: x86_64-linux
Running
gfortran src/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90 -fno-tree-ter
-funroll-loops -flive-range-shrinkage --param=max-combine-insns=2
-frounding-math -mavx512bw -O1 -fharden-conditional-branches
fails with
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90:37:17:
37 | END program main
| ^
Error: insn does not satisfy its constraints:
(insn 1129 257 258 20 (set (reg:SF 57 xmm21 [761])
(const_double:SF 0.0 [0x0.0p+0]))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90":26:56
discrim 11 160 {*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 0.0 [0x0.0p+0])
(nil)))
during RTL pass: rnreg
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90:37:17:
internal compiler error: in extract_constrain_insn, at recog.cc:2692
0x7e05f2 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.cc:108
0x7e0618 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.cc:118
0x7dec5f extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.cc:2692
0xfb64fc build_def_use
../../src/gcc/regrename.cc:1700
0xfb64fc regrename_analyze(bitmap_head*, bool)
../../src/gcc/regrename.cc:772
0xfb7539 regrename_optimize
../../src/gcc/regrename.cc:1983
0xfb7539 execute
../../src/gcc/regrename.cc:2022
gfortran -v output:
Using built-in specs.
COLLECT_GCC=../build/gcc/gfortran
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --disable-multilib --disable-libsanitizer
--enable-languages=c,c++,fortran --enable-checking --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231011 (experimental) (GCC)
[Bug c++/111771] New: Incorrect "is used uninitialized" warning, as if zero-initialization didn't propagate through user-provided default constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111771
Bug ID: 111771
Summary: Incorrect "is used uninitialized" warning, as if
zero-initialization didn't propagate through
user-provided default constructors
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamsupermouse at mail dot ru
Target Milestone: ---
Here's the code. GCC with `-Wall -O3` warns that `x` is used uninitialized,
even though it's zeroed.
struct A
{
A() {}
int x;
};
struct B : A {};
int main()
{
B b = B();
return b.x;
}
Since `B` doesn't have a user-provided default constructor, value-initializing
it like this performs zero-initialization, which propagates recursively
(http://eel.is/c++draft/dcl.dcl#dcl.init.general-6.2) over all members, zeroing
everything. Yet GCC incorrectly warns about `x` being uninitialized.
[Bug target/111768] X86: -march=native does not support alder lake big.little cache infor correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768 --- Comment #5 from Alexander Monakov --- I think it's similar to attempting -march=native under distcc, which is already warned about on Gentoo wiki: https://wiki.gentoo.org/wiki/Distcc The difference here is that Intel so far decided to make ISA feature set the same between 'performance' and 'power-efficient' cores, so the differences for -march=native detection are minimal. Intel also added a cpuid bit for hybrid CPUs, so in principle native arch detection could inspect that bit and then override l1-cache-size to 32 KiB (having the exact size in the param is not important, specifying a lower value is ok), or just drop it and let cc1 fall back to the default value (64) from params.opt. Short term, I would advise users to add --param=l1-cache-size=32 after -march=native in CFLAGS.
[Bug tree-optimization/111766] Missed optimization with __builtin_unreachable and ands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766 --- Comment #1 from Andrew Macleod --- Imports: bb_3(D) Exports: _2 bb_3(D) _2 : bb_3(D)(I) bb_3(D) [irange] int [0, 3] MASK 0x3 VALUE 0x0 : _2 = bb_3(D) & 1; if (_2 == 0) goto ; [INV] else goto ; [INV] _2 : [irange] int [0, 1] MASK 0x1 VALUE 0x0 4->5 (T) _2 : [irange] int [0, 0] MASK 0x1 VALUE 0x0 4->5 (T) bb_3(D) : [irange] int [0, 0][2, 2] MASK 0x2 VALUE 0x0 4->6 (F) _2 : [irange] int [1, 1] MASK 0x1 VALUE 0x0 4->6 (F) bb_3(D) : [irange] int [1, 3] MASK 0x2 VALUE 0x1 Looks like its just a lack of completeness in operator_bitwise_and::op1_range(). on the edge from 4->6 ranger knows _2 is [1,1], but when op1_range solves for _2 = bb_3 & 1 we have [1,1] = int [0, 3] MASK 0x3 VALUE 0x0& 1 and it produces int [1, 3] rather than [1,1][3,3]
[Bug target/111768] X86: -march=native does not support alder lake big.little cache infor correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768 --- Comment #4 from Hongtao.liu --- I checked Alderlake's L1 cachesize and it is indeed 48, and L1 cachesize in alderlake_cost is set to 32. But then again, we have a lot of different platforms that share the same cost and they may have different L1 cachesizes, but from a micro-architecture tuning point of view, it doesn't make a difference. A separate cost if only the L1 cachesize is different is quite unnecessary（the size itself is just a parameter for the software prefetch, it doesn't have to be real hardware cachesize)
[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764
--- Comment #4 from Richard Biener ---
/* Try to simplify the vector initialization by applying an
adjustment after the reduction has been performed. */
if (!reduc_info->reused_accumulator
&& STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def
&& !operand_equal_p (neutral_op, initial_def))
{
STMT_VINFO_REDUC_EPILOGUE_ADJUSTMENT (reduc_info)
= initial_def;
initial_def = neutral_op;
}
maybe just allow PLUS/MINUS_EXPR here. Maybe it's all premature ...
[Bug tree-optimization/111764] [11/12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764 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 the vectorizer transforms b = 2; for (;;) b = b * b; to b = 1; for (;;) b = b * b; b *= 2; which is obviously wrong(TM).
[Bug target/111768] X86: -march=native does not support alder lake big.little cache infor correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768 --- Comment #3 from Richard Biener --- I'd say "don't do this" (bootstrap with -march=native). Alternatively use a taskset to confine to either big or little cores.
[Bug c/111769] Annotate function definitions and calls to facilitate link-time checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769 --- Comment #1 from Richard Biener --- If you compile with debug info enabled the info should be already there, just nothing looks at this (and mismatches) at link time.
[Bug target/111768] X86: -march=native does not support alder lake big.little cache infor correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768 --- Comment #2 from Andrew Pinski --- I think on those soc we should ignore the cache info or set it to some common value between the 2.
[Bug tree-optimization/111770] predicated loads inactive lane values not modelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-10-11 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- "Generally" we need an "else" value for .MASK_LOAD and there model "don't care". Elsewhere we observed that most uarchs do zero masked elements (or at least offer so) and thus .MASK_LOAD without else value might be interpreted as doing that (until I came along in the other related PR sugggesting an omitted 'else' value means 'don't care' - but IIRC the RISC-V folks ended up implementing that with default-defs). Btw, we should possibly vectorize this with a COND_DOT_PROD, since adding zeros isn't correct for HONOR_SIGNED_ZEROS/HONOR_SIGN_DEPENDENT_ROUNDING.
[Bug tree-optimization/111770] New: predicated loads inactive lane values not modelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
Bug ID: 111770
Summary: predicated loads inactive lane values not modelled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
For this example:
int foo(int n, char *a, char *b) {
int sum = 0;
for (int i = 0; i < n; ++i) {
sum += a[i] * b[i];
}
return sum;
}
we generate with -O3 -march=armv8-a+sve
.L3:
ld1bz29.b, p7/z, [x1, x3]
ld1bz31.b, p7/z, [x2, x3]
add x3, x3, x4
sel z31.b, p7, z31.b, z28.b
whilelo p7.b, w3, w0
udotz30.s, z29.b, z31.b
b.any .L3
uaddv d30, p6, z30.s
fmovw0, s30
ret
Which is pretty good, but we completely ruin it with the SEL.
In gimple this is:
vect__7.12_81 = .MASK_LOAD (_21, 8B, loop_mask_77);
masked_op1_82 = .VCOND_MASK (loop_mask_77, vect__7.12_81, { 0, ... });
vect_patt_33.13_83 = DOT_PROD_EXPR ;
The missed optimization here is that we don't model what happens with
predicated operations that zero inactive lanes.
i.e. in this case .MASK_LOAD will zero the unactive lanes, so the .VCOND_MASK
is completely superfluous.
I'm not entirely sure how we should go about fixing this generally.
[Bug modula2/111675] Incorrect parameter value passed when attempting to pass a field of a packed record as a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111675 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/111675] Incorrect parameter value passed when attempting to pass a field of a packed record as a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111675 --- Comment #2 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:2b783fe2e8103d97db7c5d6c1514ba16091f39f6 commit r14-4556-g2b783fe2e8103d97db7c5d6c1514ba16091f39f6 Author: Gaius Mulley Date: Wed Oct 11 13:26:47 2023 +0100 PR modula2/111675 Incorrect packed record field value passed to a procedure This patch allows a packed field to be extracted and passed to a procedure. It ensures that the subrange type is the same for both the procedure and record field. It also extends the <* bytealignment (0) *> to cover packed subrange types. gcc/m2/ChangeLog: PR modula2/111675 * gm2-compiler/M2CaseList.mod (appendTree): Replace InitStringCharStar with InitString. * gm2-compiler/M2GCCDeclare.mod: Import AreConstantsEqual. (DeclareSubrange): Add zero alignment test and call BuildSmallestTypeRange if necessary. (WalkSubrangeDependants): Walk the align expression. (IsSubrangeDependants): Test the align expression. * gm2-compiler/M2Quads.mod (BuildStringAdrParam): Correct end name. * gm2-compiler/P2SymBuild.mod (BuildTypeAlignment): Allow subranges to be zero aligned (packed). * gm2-compiler/SymbolTable.mod (Subrange): Add Align field. (MakeSubrange): Set Align to NulSym. (PutAlignment): Assign Subrange.Align to align. (GetAlignment): Return Subrange.Align. * gm2-gcc/m2expr.cc (noBitsRequired): Rewrite. (calcNbits): Rename ... (m2expr_calcNbits): ... to this and test for negative values. (m2expr_BuildTBitSize): Replace calcNBits with m2expr_calcNbits. * gm2-gcc/m2expr.def (calcNbits): Export. * gm2-gcc/m2expr.h (m2expr_calcNbits): New prototype. * gm2-gcc/m2type.cc (noBitsRequired): Remove. (m2type_BuildSmallestTypeRange): Call m2expr_calcNbits. (m2type_BuildSubrangeType): Create range_type from build_range_type (type, lowval, highval). gcc/testsuite/ChangeLog: PR modula2/111675 * gm2/extensions/run/pass/packedrecord3.mod: New test. Signed-off-by: Gaius Mulley
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #9 from Tamar Christina --- (In reply to Mikael Morin from comment #8) > Created attachment 56091 [details] > Rough patch > > Here is a rough patch to make the scalarizer support minloc calls. > It regresses on minloc_1.f90 at least, but I haven't be able to pinpoint the > problem in the original tree dump so far. > > The problem could be with the initialization of loop iteration variables. > The existing code used for scalar minloc was versioning loops, that is it > was using too loops in a row in some cases. With scalar minloc, the > initialization of the loop variable could just be disabled in the second > loop, but if there is more than one dimension as in the array case, this > can't work. So the patch above initializes the loop variables conditionally > on a "loop_break" boolean variable, which I hoped the optimizers would be > able to remove. Unfortunately, this conditional initialization seems to > confuse the optimizers a lot. > > Anyway, the patch is there; not sure how much I can pursue this further in > the future. Thanks Mikael! That's already plenty of help! I can try to debug further after I finish my current patches. Would it be ok if I ask questions when I do?
[Bug fortran/90608] Inline non-scalar minloc/maxloc calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608 --- Comment #8 from Mikael Morin --- Created attachment 56091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56091&action=edit Rough patch Here is a rough patch to make the scalarizer support minloc calls. It regresses on minloc_1.f90 at least, but I haven't be able to pinpoint the problem in the original tree dump so far. The problem could be with the initialization of loop iteration variables. The existing code used for scalar minloc was versioning loops, that is it was using too loops in a row in some cases. With scalar minloc, the initialization of the loop variable could just be disabled in the second loop, but if there is more than one dimension as in the array case, this can't work. So the patch above initializes the loop variables conditionally on a "loop_break" boolean variable, which I hoped the optimizers would be able to remove. Unfortunately, this conditional initialization seems to confuse the optimizers a lot. Anyway, the patch is there; not sure how much I can pursue this further in the future.
[Bug c/111769] New: Annotate function definitions and calls to facilitate link-time checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111769 Bug ID: 111769 Summary: Annotate function definitions and calls to facilitate link-time checking Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david at westcontrol dot com Target Milestone: --- This is an enhancement idea, rather than a bug, and would require linker support as well as compiler support. In C, it is possible to define a function with one set of parameters (number and type) in one translation unit, and declare and use it with a different set in a different translation unit. This is undefined behaviour, and generally a really bad idea, but it can't be spotted by the toolchain unless you use LTO. In C++, you don't see the same effect as different name mangling would result in linker failures. Would it be possible for the C compiler, when emitting an external linkage function definition and the use (or possibly declaration) of a function (for calling or taking its address), to add a directive or debug info section entry giving the function type in active use? These could then be checked at link time, even without LTO, to catch mismatches. My suggestion would be to use the existing C++ name-mangling scheme to encode the function types. Thus the declaration and definition of "int square(int num)" would be annotated with a note that the function "square" has signature "_Z6squarei".
[Bug bootstrap/111768] Bootstrap failure with -march=native on Intel Alder Lake CPUs because of differing cache sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768 Sam James changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment #1 from Sam James --- It's unclear to me if GCC should mangle -march=native on Alder Lake CPUs, if it should ignore cache sizes during bootstrap comparison (ew), or if Intel need to be consulted to find out what sort of "consistency" guarantee is even provided here.
[Bug bootstrap/111768] New: Bootstrap failure with -march=native on Intel Alder Lake CPUs because of differing cache sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
Bug ID: 111768
Summary: Bootstrap failure with -march=native on Intel Alder
Lake CPUs because of differing cache sizes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Please bare with me on this one.
We've had a bunch of reports downstream of bootstrap failures on Intel Alder
Lake CPUs with -march=native:
* https://bugs.gentoo.org/904426
* https://bugs.gentoo.org/908523
* https://bugs.gentoo.org/915389 (this has a bit more detail)
Alder Lake has a big.little architecture.
We end up with:
```
$ diffoscope ./stage2-x86_64-pc-linux-gnu/32/libgcc/eqhf2.o
./stage3-x86_64-pc-linux-gnu/32/libgcc/eqhf2.o
```
[...]
│ - [33] GNU C17 13.2.1 20230826 -march=alderlake -mmmx -mpopcnt -msse
-msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop
-mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw
-mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi
-mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq
-mno-avx512vbmi2 -mgfni -mvpclmulqdq -mno-avx512vnni -mno-avx512bitalg
-mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote
-mclflushopt -mclwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr
-mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mmovdir64b -mmovdiri -mno-mwaitx
-mpconfig -mpku -mno-prefetchwt1 -mprfchw -mptwrite -mrdpid -mrdrnd -mrdseed
-mno-rtm -mserialize -mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes
-mwaitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-uintr -mhreset -mno-kl -mno-widekl -mavxvnni
-mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd
-mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex
--param=l1-cache-size=48 --param=l1-cache-line-size=64
--param=l2-cache-size=24576 -mtune=alderlake -m32 -mlong-double-80 -msse2 -g -g
-g -O2 -O3 -O2 -O2 -O3 -fbuilding-libgcc -fno-stack-protector
-fno-stack-clash-protection -fpic -fvisibility=hidden
│ - [ 578] _Float16
│ - [ 581] _FP_UNPACK_RAW_1_flo
│ - [ 596] long long unsigned int
│ - [ 5ad] sign
│ - [ 5b2] _fcw
│ + [33] _Float16
│ + [3c] _FP_UNPACK_RAW_1_flo
│ + [51] long long unsigned int
│ + [68] sign
│ + [6d] _fcw
│ + [72] GNU C17 13.2.1 20230826 -march=alderlake -mmmx -mpopcnt -msse
-msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop
-mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw
-mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi
-mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq
-mno-avx512vbmi2 -mgfni -mvpclmulqdq -mno-avx512vnni -mno-avx512bitalg
-mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote
-mclflushopt -mclwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr
-mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mmovdir64b -mmovdiri -mno-mwaitx
-mpconfig -mpku -mno-prefetchwt1 -mprfchw -mptwrite -mrdpid -mrdrnd -mrdseed
-mno-rtm -mserialize -mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes
-mwaitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-uintr -mhreset -mno-kl -mno-widekl -mavxvnni
-mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd
-mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex
--param=l1-cache-size=32 --param=l1-cache-line-size=64
--param=l2-cache-size=24576 -mtune=alderlake -m32 -mlong-double-80 -msse2 -g -g
-g -O2 -O3 -O2 -O2 -O3 -fbuilding-libgcc -fno-stack-protector
-fno-stack-clash-protection -fpic -fvisibility=hidden
[...]
```
$ wdiff /tmp/a /tmp/b
DW_AT_producer: (strp) (offset: [-0x33):-] {+0x72):+} GNU C17 13.2.1
20230826 -march=alderlake -mmmx -mpopcnt -msse -msse3 -mssse3 -msse4.1 -msse4.2
-mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2
-maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd
-mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw
-mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mgfni -mvpclmulqdq
-mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect
-mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mno-clzero -mcx16
-mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe
-mmovdir64b -mmovdiri -mno-mwaitx -mpconfig -mpku -mno-prefetchwt1 -mprfchw
-mptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mserialize -mno-sgx -msha -mshstk
-mno-tbm -mno-tsxldtrk -mvaes -mwaitpkg -mno-wbnoinvd -mxsave -mxsavec
-mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr
-mhreset -mno-kl -mno-widekl -ma
[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- That is still ICE on valid code, the code with the out of bounds access or some other UB might not be ever reachable at runtime, it can even not appear in the source at all and can be just a result of jump threading on unrelated condition etc. So I think we certainly want to backport it.
[Bug tree-optimization/111760] risc-v regression: COND_LEN_* incorrect fold/simplify in middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111760 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #7 from Richard Biener --- But Richard S. invented the "conditional" op stuff in folding (I was also waiting for him to look at Robins patch).
[Bug preprocessor/111767] New: cast __mmask32 parameter to __mmask8 from macro function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111767 Bug ID: 111767 Summary: cast __mmask32 parameter to __mmask8 from macro function Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: joony.wie at samsung dot com Target Milestone: --- the macro function cast the parameter "u" to __mmask8 for debug build. but the "u" should be __mmask32. /* Intrinsics vfpclassph. */ #ifdef __OPTIMIZE__ _mm512_mask_fpclass_ph_mask (__mmask32 __U, __m512h __A, const int __imm); #else #define _mm512_mask_fpclass_ph_mask(u, x, c)\ ((__mmask32) __builtin_ia32_fpclassph512_mask ((__v32hf) (__m512h) (x), \ (int) (c),(__mmask8)(u))) #endif /* __OPIMTIZE__ */
[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Roger Sayle --- This should now be fixed on mainline.
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519 --- Comment #10 from CVS Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:16a4df27436c8f594a784028591dd3e47cabe5c0 commit r13-7944-g16a4df27436c8f594a784028591dd3e47cabe5c0 Author: Jakub Jelinek Date: Wed Oct 11 08:58:29 2023 +0200 tree-ssa-strlen: optimization skips clobbering store [PR111519] The following testcase is miscompiled, because count_nonzero_bytes incorrectly uses get_strinfo information on a pointer from which an earlier instruction loads SSA_NAME stored at the current instruction. get_strinfo shows a state right before the current store though, so if there are some stores in between the current store and the load, the string length information might have changed. The patch passes around gimple_vuse from the store and punts instead of using strinfo on loads from MEM_REF which have different gimple_vuse from that. 2023-10-11 Richard Biener Jakub Jelinek PR tree-optimization/111519 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes): Add vuse argument and pass it through to recursive calls and count_nonzero_bytes_addr calls. Don't shadow the stmt argument, but change stmt for gimple_assign_single_p statements for which we don't immediately punt. (strlen_pass::count_nonzero_bytes_addr): Add vuse argument and pass it through to recursive calls and count_nonzero_bytes calls. Don't use get_strinfo if gimple_vuse (stmt) is different from vuse. Don't shadow the stmt argument. * gcc.dg/torture/pr111519.c: New testcase. (cherry picked from commit e75bf1985fdc9a5d3a307882a9251d8fd6e93def)
[Bug tree-optimization/111519] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r13-455-g1fe04c497d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e75bf1985fdc9a5d3a307882a9251d8fd6e93def commit r14-4552-ge75bf1985fdc9a5d3a307882a9251d8fd6e93def Author: Jakub Jelinek Date: Wed Oct 11 08:58:29 2023 +0200 tree-ssa-strlen: optimization skips clobbering store [PR111519] The following testcase is miscompiled, because count_nonzero_bytes incorrectly uses get_strinfo information on a pointer from which an earlier instruction loads SSA_NAME stored at the current instruction. get_strinfo shows a state right before the current store though, so if there are some stores in between the current store and the load, the string length information might have changed. The patch passes around gimple_vuse from the store and punts instead of using strinfo on loads from MEM_REF which have different gimple_vuse from that. 2023-10-11 Richard Biener Jakub Jelinek PR tree-optimization/111519 * tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes): Add vuse argument and pass it through to recursive calls and count_nonzero_bytes_addr calls. Don't shadow the stmt argument, but change stmt for gimple_assign_single_p statements for which we don't immediately punt. (strlen_pass::count_nonzero_bytes_addr): Add vuse argument and pass it through to recursive calls and count_nonzero_bytes calls. Don't use get_strinfo if gimple_vuse (stmt) is different from vuse. Don't shadow the stmt argument. * gcc.dg/torture/pr111519.c: New testcase.
[Bug tree-optimization/106245] Failure to optimize (u8)(a << 7) >> 7 pattern to a & 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106245
--- Comment #2 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:c41492423140e1573df68d1c98e825ae7593741f
commit r14-4551-gc41492423140e1573df68d1c98e825ae7593741f
Author: Roger Sayle
Date: Wed Oct 11 08:08:04 2023 +0100
Optimize (ne:SI (subreg:QI (ashift:SI x 7) 0) 0) as (and:SI x 1).
This patch is the middle-end piece of an improvement to PRs 101955 and
106245, that adds a missing simplification to the RTL optimizers.
This transformation is to simplify (char)(x << 7) != 0 as x & 1.
Technically, the cast can be any truncation, where shift is by one
less than the narrower type's precision, setting the most significant
(only) bit from the least significant bit.
This transformation applies to any target, but it's easy to see
(and add a new test case) on x86, where the following function:
int f(int a) { return (a << 31) >> 31; }
currently gets compiled with -O2 to:
foo:movl%edi, %eax
sall$7, %eax
sarb$7, %al
movsbl %al, %eax
ret
but with this patch, we now generate the slightly simpler.
foo:movl%edi, %eax
sall$31, %eax
sarl$31, %eax
ret
2023-10-11 Roger Sayle
gcc/ChangeLog
PR middle-end/101955
PR tree-optimization/106245
* simplify-rtx.cc (simplify_relational_operation_1): Simplify
the RTL (ne:SI (subreg:QI (ashift:SI x 7) 0) 0) to (and:SI x 1).
gcc/testsuite/ChangeLog
* gcc.target/i386/pr106245-1.c: New test case.
[Bug middle-end/101955] (signed<<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101955
--- Comment #7 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:c41492423140e1573df68d1c98e825ae7593741f
commit r14-4551-gc41492423140e1573df68d1c98e825ae7593741f
Author: Roger Sayle
Date: Wed Oct 11 08:08:04 2023 +0100
Optimize (ne:SI (subreg:QI (ashift:SI x 7) 0) 0) as (and:SI x 1).
This patch is the middle-end piece of an improvement to PRs 101955 and
106245, that adds a missing simplification to the RTL optimizers.
This transformation is to simplify (char)(x << 7) != 0 as x & 1.
Technically, the cast can be any truncation, where shift is by one
less than the narrower type's precision, setting the most significant
(only) bit from the least significant bit.
This transformation applies to any target, but it's easy to see
(and add a new test case) on x86, where the following function:
int f(int a) { return (a << 31) >> 31; }
currently gets compiled with -O2 to:
foo:movl%edi, %eax
sall$7, %eax
sarb$7, %al
movsbl %al, %eax
ret
but with this patch, we now generate the slightly simpler.
foo:movl%edi, %eax
sall$31, %eax
sarl$31, %eax
ret
2023-10-11 Roger Sayle
gcc/ChangeLog
PR middle-end/101955
PR tree-optimization/106245
* simplify-rtx.cc (simplify_relational_operation_1): Simplify
the RTL (ne:SI (subreg:QI (ashift:SI x 7) 0) 0) to (and:SI x 1).
gcc/testsuite/ChangeLog
* gcc.target/i386/pr106245-1.c: New test case.
