[Bug tree-optimization/105903] Missed optimization for __synth3way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > After my patches for PR 96923 (and PR 100864), we get: > > > _22 = _16 > _17; > ... (some dead statements that PHI-OPT adds due to match and simplify) > _8 = _16 >= _17; > _13 = _8 & _22; > > But there is nothing which optimizes the above into just _22 (_16 > _17) > which I find interesting ... Now after the patch I have for 106164 we get: _13 = _16 > _17; Which is what we expect. Note phiopt still should do some cleanup because of match-and-simplify as we get: _3 = _16 < _17; _7 = _16 < _17; _8 = _16 >= _17; _13 = _16 > _17; Where _3, _7 and _8 are all unused, I have to figure out the best way of doing that.
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
--- Comment #4 from Andrew Pinski ---
This is the match.pd code:
(for bitop (bit_and bit_ior)
(for cmp (tcc_comparison)
(for ocmp (tcc_comparison)
(for ncmp (tcc_comparison)
(simplify
(bitop (cmp:c @0 @1) (ocmp @0 @1))
(with {
#if GIMPLE
location_t loc = UNKNOWN_LOCATION;
#endif
tree t = combine_comparisons (loc,
bitop == BIT_IOR_EXPR
? TRUTH_ORIF_EXPR : TRUTH_ANDIF_EXPR,
cmp, ocmp,
type, @0, @1);
}
(switch
(if (GENERIC && t)
{t;})
(if (t && CONSTANT_CLASS_P (t))
{t;})
(if (t && TREE_CODE (t) == ncmp
/* Even though combine_comparisons should
return this, this is to double check. */
&& operand_equal_p (TREE_OPERAND (t, 0), @0)
&& operand_equal_p (TREE_OPERAND (t, 1), @1))
(ncmp @0 @1)
)
)
)
)
)
)
)
)
I am not a fan of it though, I think we should change combine_comparisons to
return the comparison code or true/false or error out.
The loc is due to combine_comparisons building the tree rather than match. The
same is true of the whole checking of the result. I am going to test this fully
and see if there is anything I need to change (there might be some testcases
which need to be "improved").
Also the whole ncmp for loop is still another issue which is a genmatch change
to allow a non-name to be there but that is so so much harder to fix and there
is already a case like that too.
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > (In reply to Andrew Pinski from comment #1) > > This is done by fold_range_test in fold-const.cc > > Actually no, it is fold_truth_andor_1. Anyways I am going to fix this one. That is combine_comparisons.
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-07-02 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > This is done by fold_range_test in fold-const.cc Actually no, it is fold_truth_andor_1. Anyways I am going to fix this one.
[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- -fexcess-precision=standard (-std=c99 enables -fexcess-precision=standard) or -mfpmath=sse fixes the issue. This is not wrong code but rather the way x87 works for GCC. GCC defaults to using the execess precision of x87 (80bits) and sometimes if the floating point value is kept on the fpu stack, there is no rounding back to 64bits. And that is exactly what you are seeing here really. Anyways this is a dup of bug 323. The reason why it works for the non-inline floor case is because well there is a rounding step that happens. The reason why -fexcess-precision=standard works (it is only implemented for the C front-end) is because there rounding steps are now explict in the IR and will use the 80bit fpu and then force the rounding back. The reason why -mfpmath=sse works is instead of using x87, GCC will use the sse fpu implementation which is 64bit without excess precision. This is kinda not a bug, just you not understanding fpu and execess precision. *** This bug has been marked as a duplicate of bug 323 ***
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Andrew Pinski changed: What|Removed |Added CC||xeioexception at gmail dot com --- Comment #224 from Andrew Pinski --- *** Bug 106165 has been marked as a duplicate of this bug. ***
[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165 --- Comment #1 from xeioex --- TO fix the last confirmations 1) gcc -O2 minified_to_string_radix.i -o 507 -lm && ./507 1e+23.toString(36) = ga894a06ac8 ERROR expected "ga894a06abs" 2) gcc -O1 minified_to_string_radix.i -o 507 -lm && ./507 1e+23.toString(36) = ga894a06abs OK 3) gcc -O1 -ffast-math minified_to_string_radix.i -o 507 -lm && ./507 1e+23.toString(36) = ga894a06abs OK 4) gcc -O1 -fstrict-aliasing minified_to_string_radix.i -o 507 -lm && ./507 1e+23.toString(36) = ga894a06abs OK 5) removing inlined floor() fixed the issue 6) clang-6.0 -O2 minified_to_string_radix.i -o 507 -lm && ./507 1e+23.toString(36) = ga894a06abs
[Bug c++/106166] New: Improve diagnostic for explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106166
Bug ID: 106166
Summary: Improve diagnostic for explicit constructor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
This is not valid code:
struct E { explicit E(int); };
void
g ()
{
E e = 1; // error
}
but we only say
q1.C:5:9: error: conversion from ‘int’ to non-scalar type ‘E’ requested
5 | E e = 1; // error
It would be nice to explain that an explicit constructor is not a candidate in
copy-initialization context.
[Bug c++/91429] Conditional explicit not respected with out-of-line definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91429 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Fixed in r11-371-g661232da72d29f.
[Bug c/106165] New: incorrect result when using inlined asm implementation of floor() on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106165 Bug ID: 106165 Summary: incorrect result when using inlined asm implementation of floor() on i686 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: xeioexception at gmail dot com Target Milestone: --- $ gcc-11 -v -save-temps -O2 minified_to_string_radix.i -o 507 -lm Using built-in specs. COLLECT_GCC=gcc-11 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/11/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.1.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/READM E.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 - -program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threa ds=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdc xx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos -checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror --disabl e-cet --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686 -linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic' '-march=i686' '-dumpdir' '507-' /usr/lib/gcc/i686-linux-gnu/11/cc1 -E -quiet -v -imultiarch i386-linux-gnu 507_mini.c -mtune=generic -march=i686 -O2 -fpch-preprocess - fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -o 507-507_mini.i ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/11/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/11/../../../../i686-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-linux-gnu/11/include /usr/local/include /usr/include/i386-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic' '-march=i686' '-dumpdir' '507-' /usr/lib/gcc/i686-linux-gnu/11/cc1 -fpreprocessed 507-507_mini.i -quiet -dumpdir 507- -dumpbase 507_mini.c -dumpbase-ext .c -mtune=generic -march=i686 -O2 -version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security -o 507-507_mini.s GNU C17 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (i686-linux-gnu) compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (i686-linux-gnu) compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 81b68deb607ea376c8bc5126cafbdd31 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic' '-march=i686' '-dumpdir' '507-' as -v --32 -o 507-507_mini.o 507-507_mini.s GNU assembler version 2.30 (i686-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30 COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/11/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/11/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/11/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic' '-march=i686' '-dumpdir' '507.' /usr/lib/gcc/i686-linux-gnu/11/collect2 -plugin /usr/lib/gcc/i686-linux-gnu/11/liblto_plugin.so -plugin-opt=/usr/lib/gcc/i686-linux-gnu/11/lto-wrapper -plugin-opt=-fresolution=507.res
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #1 from Andrew Pinski --- This is done by fold_range_test in fold-const.cc
[Bug tree-optimization/106163] generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106163 --- Comment #2 from Andrew Pinski --- Most likely the code here needs to be changed slightly. fprintf_indent (f, indent, "if (TREE_SIDE_EFFECTS (captures[%d]))\n", i); Or maybe the code which sets TREE_SIDE_EFFECTS should be fixed ...
[Bug tree-optimization/106164] New: (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164
Bug ID: 106164
Summary: (a > b) & (a >= b) does not get optimized until
reassoc1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 105903
Target Milestone: ---
Take:
```
_Bool f(int a, int b)
{
_Bool c = a > b;
_Bool d = a >= b;
return c & d;
}
```
This does not get optimized until reassoc1.
While:
```
_Bool f(int a, int b)
{
return (a > b) & (a >= b);
}
```
Gets optimized during folding (not by match though), I have not looked into
what does it though.
I noticed this while working on PR 105903 as there is not a reassoc pass after
phiopt4 so nothing optimizes.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903
[Bug 105903] Missed optimization for __synth3way
[Bug tree-optimization/106163] generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106163 --- Comment #1 from Ian Lance Taylor --- This was originally reported against gccgo at https://go.dev/issue/53019.
[Bug tree-optimization/106163] New: generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106163
Bug ID: 106163
Summary: generic-match does not honor -fnon-call-exceptions
-fno-delete-dead-exceptions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
When using -fnon-call-exceptions -fno-delete-dead-exceptions memory operations
that are not marked TREE_THIS_NOTRAP should not be removed from the execution
path. However, the generic_simplify function, at least, does not honor this.
This test case, when compiled with -fnon-call-exceptions
-fno-delete-dead-exceptions, should exit with a zero status. However, it
currently fails, because "i = *p ^ *p;" is simplified to "i = 0;".
// { dg-do run { target { i?86-*-linux* i?86-*-gnu* x86_64-*-linux* } } }
// { dg-additional-options "-fexceptions -fnon-call-exceptions
-fno-delete-dead-exceptions" }
#include
#include
#include
static void
sighandler (int signo, siginfo_t* si, void* uc)
{
throw (5);
}
struct S { void *p1, *p2; };
struct S v;
__attribute__ ((noinline))
int
dosegv ()
{
int *p = 0;
int i __attribute__((unused)) = 0;
i = *p ^ *p;
return 0;
}
int main ()
{
struct sigaction sa;
memset (, 0, sizeof sa);
sa.sa_sigaction = sighandler;
sigaction (SIGSEGV, , NULL);
sigaction (SIGBUS, , NULL);
try {
dosegv ();
}
catch (int x) {
return (x != 5);
}
return 1;
}
[Bug tree-optimization/105903] Missed optimization for __synth3way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903 --- Comment #5 from Andrew Pinski --- After my patches for PR 96923 (and PR 100864), we get: _22 = _16 > _17; ... (some dead statements that PHI-OPT adds due to match and simplify) _8 = _16 >= _17; _13 = _8 & _22; But there is nothing which optimizes the above into just _22 (_16 > _17) which I find interesting ...
[Bug tree-optimization/105903] Missed optimization for __synth3way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903 --- Comment #4 from Andrew Pinski --- Created attachment 53237 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53237=edit testcase Even though it was included in comment #0, I am attaching it as it easier to figure out what the testcase was.
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.5
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162 --- Comment #8 from Jonathan Wakely --- Fixed on trunk, but worth backporting to all branches.
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:8a6ee426c2be3bd4359520e02c00ec60cac2fece
commit r13-1400-g8a6ee426c2be3bd4359520e02c00ec60cac2fece
Author: Jonathan Wakely
Date: Fri Jul 1 22:23:43 2022 +0100
libstdc++: Add missing prerequisite to generated header [PR106162]
The ${host_builddir}/largefile-config.h header can't be written until
its parent directory has been created, so it needs to have the creation
of that directory as a prerequisite.
libstdc++-v3/ChangeLog:
PR libstdc++/106162
* include/Makefile.am (largefile-config.h): Add
stamp-${host_alias} prerequisite.
* include/Makefile.in: Regenerate.
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162 --- Comment #6 from Sergei Trofimovich --- (In reply to Jonathan Wakely from comment #2) > (In reply to Sergei Trofimovich from comment #0) > > There is a race condition when (I speculate) libstdcv++v3 is built in > > parallel from different 'make' processes. Perhaps for c++98 | c++11 | x++17 > > instances? > > There are no such instances. It is built separately for each multilib, but > each of those has its own $host_builddir Aha, TIL! > Are you 100% sure you didn't actually run multiple make processes yourself, > e.g by using & instead of && in a shell command? I was running it from a standard build script. Should be just 'make -j16 -l16' (with a small caveat: make is built with --shuffle support to reorder what what is allowed to expose missing depends: https://savannah.gnu.org/bugs/index.php?62100). (In reply to Jonathan Wakely from comment #5) > Created attachment 53236 [details] > Add missing prerequisite to generated header > > I'm testing this. Thank you! I'll also give it a go locally and will complain if it fails in a similar way.
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-07-01 --- Comment #5 from Jonathan Wakely --- Created attachment 53236 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53236=edit Add missing prerequisite to generated header I'm testing this.
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162
--- Comment #4 from Jonathan Wakely ---
The header target is missing a prerequisite of stamp-${host_alias}
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162 --- Comment #3 from Jonathan Wakely --- I think the errors are actually saying the directory doesn't exist, and are coming from the three shell commands that redirect to that rule using >> $@.tmp
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162
--- Comment #2 from Jonathan Wakely ---
(In reply to Sergei Trofimovich from comment #0)
> There is a race condition when (I speculate) libstdcv++v3 is built in
> parallel from different 'make' processes. Perhaps for c++98 | c++11 | x++17
> instances?
There are no such instances. It is built separately for each multilib, but each
of those has its own $host_builddir
>
> From libstdc++-v3/include/Makefile.am:
>
> # This header is not installed, it's only used to build libstdc++ itself.
> ${host_builddir}/largefile-config.h: ${CONFIG_HEADER}
> @rm -f $@.tmp
> @-grep 'define _DARWIN_USE_64_BIT_INODE' ${CONFIG_HEADER} >> $@.tmp
> @-grep 'define _FILE_OFFSET_BITS' ${CONFIG_HEADER} >> $@.tmp
> @-grep 'define _LARGE_FILES' ${CONFIG_HEADER} >> $@.tmp
> @mv $@.tmp $@
>
> As a result 'bits/largefile-config.h' rule gets executed in parallel and
I don't see how that's possible. It's a prerequisite of c++config.h which is
built once per multilib, and parallel make processes will coordinate to only
build the prereq once.
Are you 100% sure you didn't actually run multiple make processes yourself, e.g
by using & instead of && in a shell command?
[Bug tree-optimization/105860] [10/11/12/13 Regression] Miscompilation causing clobbered union contents since r10-918-gc56c86024f8fba0c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860 --- Comment #6 from Martin Jambor --- I proposed a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597674.html
[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95107 --- Comment #9 from anlauf at gcc dot gnu.org --- The issue can be studied by playing with option -fmax-stack-var-size=n. -fno-automatic corresponds to n=0; using n=64 and higher lets the code compile. There's something weird going on here.
[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105954 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bac42273343bb9a198704900e2118ed4e84cb23a commit r10-10878-gbac42273343bb9a198704900e2118ed4e84cb23a Author: Harald Anlauf Date: Mon Jun 20 20:59:55 2022 +0200 Fortran: handle explicit-shape specs with constant bounds [PR105954] gcc/fortran/ChangeLog: PR fortran/105954 * decl.c (variable_decl): Adjust upper bounds for explicit-shape specs with constant bound expressions to ensure non-negative extents. gcc/testsuite/ChangeLog: PR fortran/105954 * gfortran.dg/pr105954.f90: New test. (cherry picked from commit a312407bd715647f7c11b67e0a52effc94d0f15d)
[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105954 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7296a7c9aa35a9731a73e33c29f6bbc488a0c837 commit r11-10103-g7296a7c9aa35a9731a73e33c29f6bbc488a0c837 Author: Harald Anlauf Date: Mon Jun 20 20:59:55 2022 +0200 Fortran: handle explicit-shape specs with constant bounds [PR105954] gcc/fortran/ChangeLog: PR fortran/105954 * decl.c (variable_decl): Adjust upper bounds for explicit-shape specs with constant bound expressions to ensure non-negative extents. gcc/testsuite/ChangeLog: PR fortran/105954 * gfortran.dg/pr105954.f90: New test. (cherry picked from commit a312407bd715647f7c11b67e0a52effc94d0f15d)
[Bug middle-end/105860] [10/11/12/13 Regression] Miscompilation causing clobbered union contents since r10-918-gc56c86024f8fba0c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Martin Jambor --- Mine.
[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162 --- Comment #1 from Sergei Trofimovich --- Created attachment 53235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53235=edit build.log.xz
[Bug libstdc++/106162] New: libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106162
Bug ID: 106162
Summary: libstdc++v3: bits/largefile-config.h.tmp: No such file
or directory race condition
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
Target Milestone: ---
There is a race condition when (I speculate) libstdcv++v3 is built in parallel
from different 'make' processes. Perhaps for c++98 | c++11 | x++17 instances?
>From libstdc++-v3/include/Makefile.am:
# This header is not installed, it's only used to build libstdc++ itself.
${host_builddir}/largefile-config.h: ${CONFIG_HEADER}
@rm -f $@.tmp
@-grep 'define _DARWIN_USE_64_BIT_INODE' ${CONFIG_HEADER} >> $@.tmp
@-grep 'define _FILE_OFFSET_BITS' ${CONFIG_HEADER} >> $@.tmp
@-grep 'define _LARGE_FILES' ${CONFIG_HEADER} >> $@.tmp
@mv $@.tmp $@
As a result 'bits/largefile-config.h' rule gets executed in parallel and
clobbers temporary file on this week's gcc-13 snapshot:
...
make[3]: Entering directory '/build/build/x86_64-w64-mingw32/libstdc++-v3'
Making all in include
make[4]: Entering directory
'/build/build/x86_64-w64-mingw32/libstdc++-v3/include'
echo 1 > stamp-dual-abi
echo 1 > stamp-allocator-new
echo timestamp > stamp-pb
echo 1 > stamp-cxx11-abi
echo 0 > stamp-visibility
echo 1 > stamp-extern-template
echo 0 > stamp-namespace-version
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
/nix/store/xsq6y0yn5mbmyazn51c86kz9zkr357xj-bash-5.1-p16/bin/bash: line 1:
x86_64-w64-mingw32/bits/largefile-config.h.tmp: No such file or directory
make[4]: [Makefile:1785: x86_64-w64-mingw32/bits/largefile-config.h] Error 1
(ignored) shuffle=1656692854
/nix/store/xsq6y0yn5mbmyazn51c86kz9zkr357xj-bash-5.1-p16/bin/bash: line 1:
x86_64-w64-mingw32/bits/largefile-config.h.tmp: No such file or directory
make[4]: [Makefile:1786: x86_64-w64-mingw32/bits/largefile-config.h] Error 1
(ignored) shuffle=1656692854
/nix/store/xsq6y0yn5mbmyazn51c86kz9zkr357xj-bash-5.1-p16/bin/bash: line 1:
x86_64-w64-mingw32/bits/largefile-config.h.tmp: No such file or directory
make[4]: [Makefile:1787: x86_64-w64-mingw32/bits/largefile-config.h] Error 1
(ignored) shuffle=1656692854
mv: cannot stat 'x86_64-w64-mingw32/bits/largefile-config.h.tmp': No such file
or directory
make[4]: *** [Makefile:1788: x86_64-w64-mingw32/bits/largefile-config.h] Error
1 shuffle=1656692854
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory
'/build/build/x86_64-w64-mingw32/libstdc++-v3/include'
make[3]: *** [Makefile:576: all-recursive] Error 1 shuffle=1656692854
make[3]: Leaving directory '/build/build/x86_64-w64-mingw32/libstdc++-v3'
make[2]: *** [Makefile:501: all] Error 2 shuffle=1656692854
make[2]: Leaving directory '/build/build/x86_64-w64-mingw32/libstdc++-v3'
make[1]: *** [Makefile:12287: all-target-libstdc++-v3] Error 2
shuffle=1656692854
make[1]: Leaving directory '/build/build'
make: *** [Makefile:1031: all] Error 2 shuffle=1656692854
Note how 'largefile-config.h.tmp: No such file or directory' is reported 3
times.
Will attach full build.log in case it makes the error cause clearer.
[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105691 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.5 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed for all open branches. Closing. Thanks for the report!
[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105691 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e6db08d9183b80b0ada5122fae79412544279f56 commit r10-10877-ge6db08d9183b80b0ada5122fae79412544279f56 Author: Harald Anlauf Date: Tue Jun 21 23:20:18 2022 +0200 Fortran: fix simplification of INDEX(str1,str2) [PR105691] gcc/fortran/ChangeLog: PR fortran/105691 * simplify.c (gfc_simplify_index): Replace old simplification code by the equivalent of the runtime library implementation. Use HOST_WIDE_INT instead of int for string index, length variables. gcc/testsuite/ChangeLog: PR fortran/105691 * gfortran.dg/index_6.f90: New test. (cherry picked from commit ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)
[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105691 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:614d9e76b71df6c5ad42f2b9c2a8156e8b3ebd35 commit r11-10102-g614d9e76b71df6c5ad42f2b9c2a8156e8b3ebd35 Author: Harald Anlauf Date: Tue Jun 21 23:20:18 2022 +0200 Fortran: fix simplification of INDEX(str1,str2) [PR105691] gcc/fortran/ChangeLog: PR fortran/105691 * simplify.c (gfc_simplify_index): Replace old simplification code by the equivalent of the runtime library implementation. Use HOST_WIDE_INT instead of int for string index, length variables. gcc/testsuite/ChangeLog: PR fortran/105691 * gfortran.dg/index_6.f90: New test. (cherry picked from commit ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)
[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106126 --- Comment #20 from David Binderman --- (In reply to David Binderman from comment #19) > I have a third test case. I suspect it is a duplicate of #2, > but could I ask you to confirm this, please ? > > It is part of the same package as #2, wxWidgets. I checked here and all is in order.
[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105813 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.5 --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed for all open branches. Closing. Thanks for the report!
[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105813 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1214ebb39cd250fda678ec89c785fcea86888a89 commit r10-10876-g1214ebb39cd250fda678ec89c785fcea86888a89 Author: Harald Anlauf Date: Fri Jun 24 22:21:39 2022 +0200 Fortran: fix checking of arguments to UNPACK when MASK is a variable [PR105813] gcc/fortran/ChangeLog: PR fortran/105813 * check.c (gfc_check_unpack): Try to simplify MASK argument to UNPACK so that checking of the VECTOR argument can work when MASK is a variable. gcc/testsuite/ChangeLog: PR fortran/105813 * gfortran.dg/unpack_vector_1.f90: New test. (cherry picked from commit f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40)
[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105813 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9902f93edd43853cd958b2e124878865da69a177 commit r11-10101-g9902f93edd43853cd958b2e124878865da69a177 Author: Harald Anlauf Date: Fri Jun 24 22:21:39 2022 +0200 Fortran: fix checking of arguments to UNPACK when MASK is a variable [PR105813] gcc/fortran/ChangeLog: PR fortran/105813 * check.c (gfc_check_unpack): Try to simplify MASK argument to UNPACK so that checking of the VECTOR argument can work when MASK is a variable. gcc/testsuite/ChangeLog: PR fortran/105813 * gfortran.dg/unpack_vector_1.f90: New test. (cherry picked from commit f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40)
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed for 11.4/12.2/13.
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:252e9dfee9b1d01e0e44773ad83e0e44f3650945 commit r11-10100-g252e9dfee9b1d01e0e44773ad83e0e44f3650945 Author: Jason Merrill Date: Thu Jun 23 23:14:35 2022 -0400 c++: dependent generic lambda template-id [PR106024] We were wrongly looking up the generic lambda op() in a dependent scope, and then trying to look up its instantiation at substitution time, but lambdas aren't instantiated, so we crashed. The fix is to not look into dependent lambda scopes. PR c++/106024 gcc/cp/ChangeLog: * parser.c (cp_parser_lookup_name): Don't look in dependent lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-generic10.C: New test.
[Bug c++/100252] [10/11/12 Regression] Internal compiler error during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252 Bug 100252 depends on bug 105550, which changed state. Bug 105550 Summary: Missing copy elision with conditional operator https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/105550] Missing copy elision with conditional operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed for GCC 13.
[Bug c++/105550] Missing copy elision with conditional operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ecd11acacd6be57af930fa617d7c31ecb40e7f74
commit r13-1397-gecd11acacd6be57af930fa617d7c31ecb40e7f74
Author: Marek Polacek
Date: Wed May 25 18:11:31 2022 -0400
c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]
In this problem, we are failing to properly perform copy elision with
a conditional operator, so this:
constexpr A a = true ? A{} : A{};
fails with:
error: 'A{((const A*)(&))}' is not a constant expression
The whole initializer is
TARGET_EXPR }> : TARGET_EXPR }>>
where the outermost TARGET_EXPR is elided, but not the nested ones.
Then we end up replacing the PLACEHOLDER_EXPRs with the temporaries the
TARGET_EXPRs represent, which is precisely what should *not* happen with
copy elision.
I've tried the approach of tweaking ctx->object, but I ran into gazillion
problems with that. I thought that I would let
cxx_eval_constant_expression
/TARGET_EXPR create a new object only when ctx->object was null, then
adjust setting of ctx->object in places like cxx_bind_parameters_in_call
and cxx_eval_component_reference but that failed completely. Sometimes
ctx->object has to be reset, sometimes it cannot be reset, 'this' needed
special handling, etc. I gave up.
Instead, this patch strips TARGET_EXPRs from the operands of ?: like
we do in various other places in constexpr.c.
PR c++/105550
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_conditional_expression): Strip
TARGET_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/nsdmi-aggr16.C: Remove FIXME.
* g++.dg/cpp1y/nsdmi-aggr17.C: Remove FIXME.
* g++.dg/cpp0x/constexpr-elision1.C: New test.
* g++.dg/cpp1y/constexpr-elision1.C: New test.
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e748398b3ef6412ef35b85ef6b0893809aeb49cd commit r12-8537-ge748398b3ef6412ef35b85ef6b0893809aeb49cd Author: Jason Merrill Date: Fri Jul 1 11:02:54 2022 -0400 c++: simpler fix for PR106024 Actually, for release branches let's just avoid the lookup for the lambdas that are the problematic case and only make the bigger change on trunk. PR c++/106024 gcc/cp/ChangeLog: * parser.cc (cp_parser_lookup_name): Limit previous change to lambdas.
[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Joseph S. Myers --- Now also applied to GCC 12 branch, so fixed for GCC 12.2.
[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Joseph Myers : https://gcc.gnu.org/g:962e7f0803f163f9cf44d64a2e199935d3f361fe commit r12-8536-g962e7f0803f163f9cf44d64a2e199935d3f361fe Author: Vladimir Makarov Date: Sat May 28 12:08:38 2022 -0600 Fix ICE on sh gcc/ PR target/103722 * config/sh/sh.cc (sh_register_move_cost): Avoid cost "2" (which is special) for various scenarios. (cherry picked from commit ce1580252ea57de23a595e9804ea87ed4353aa6a)
[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106111 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed for GCC 13.
[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106111 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2ea6c59349793761b9c00f75ef281ac413566b2f commit r13-1394-g2ea6c59349793761b9c00f75ef281ac413566b2f Author: Marek Polacek Date: Tue Jun 28 18:59:19 2022 -0400 c++: warn about using keywords as identifiers [PR106111] In C++03, -Wc++11-compat should warn about int constexpr; since 'constexpr' is a keyword in C++11. Jonathan reports that we don't emit a similar warning for 'alignas' or 'alignof', and, as I found out, 'thread_local'. Similarly, we don't warn for most C++20 keywords. That happens because RID_LAST_CXX20 hasn't been updated in a while. PR c++/106111 gcc/c-family/ChangeLog: * c-common.h (enum rid): Update RID_LAST_CXX20. gcc/cp/ChangeLog: * parser.cc (cp_lexer_get_preprocessor_token): Also warn about RID_ALIGNOF, RID_ALIGNAS, RID_THREAD. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/keywords1.C: New test. * g++.dg/cpp2a/keywords1.C: New test.
[Bug demangler/105039] rust demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- Patch applied.
[Bug demangler/105039] rust demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 --- Comment #4 from CVS Commits --- The master branch has been updated by Nick Clifton : https://gcc.gnu.org/g:9234cdca6ee88badfc00297e72f13dac4e540c79 commit r13-1393-g9234cdca6ee88badfc00297e72f13dac4e540c79 Author: Nick Clifton Date: Fri Jul 1 15:58:52 2022 +0100 Add a recursion limit to the demangle_const function in the Rust demangler. libiberty/ PR demangler/105039 * rust-demangle.c (demangle_const): Add recursion limit.
[Bug c++/105964] [12 Regression] Return type deduction fails during NTTP use of function dependent on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105964 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 12.2.
[Bug c++/105908] [12 Regression] out-of-class definition of templated method with decltype in trailing return type fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105908 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for 12.2.
[Bug c++/105541] [12 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jason Merrill --- Fixed for 12.2.
[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105779 --- Comment #10 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aefe23f720a542e90ecc6629885b01d44139b043 commit r13-1392-gaefe23f720a542e90ecc6629885b01d44139b043 Author: Jason Merrill Date: Fri Jul 1 00:37:10 2022 -0400 c++: tweak resolve_args change I don't know why I used tf_error instead of complain here. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Use complain.
[Bug c++/105541] [12 Regression] ICE: Segmentation fault when template lambda in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b1c8ee2627696717013ebdb1ca3f5f97a76b1cb9 commit r12-8535-gb1c8ee2627696717013ebdb1ca3f5f97a76b1cb9 Author: Jason Merrill Date: Wed May 11 14:53:26 2022 -0400 c++: lambda template in requires [PR105541] Since the patch for PR103408, the template parameters for the lambda in this test have level 1 instead of 2, and we were treating null template args as 1 level of arguments, so tsubst_template_parms decided it had nothing to do. Fixed by distinguishing between <> and no args at all, which is what we have in our "substitution" in a requires-expression. PR c++/105541 gcc/cp/ChangeLog: * cp-tree.h (TMPL_ARGS_DEPTH): 0 for null args. * parser.cc (cp_parser_enclosed_template_argument_list): Use 0-length TREE_VEC for <>. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-requires1.C: New test.
[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105779 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:d9130880f77c7f9ffd5deaabda605bc151521be5 commit r12-8534-gd9130880f77c7f9ffd5deaabda605bc151521be5 Author: Jason Merrill Date: Fri Jul 1 00:37:10 2022 -0400 c++: tweak resolve_args change I don't know why I used tf_error instead of complain here. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Use complain.
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c17206709f94331e81443e2bdcf135a6ab7428ce commit r12-8533-gc17206709f94331e81443e2bdcf135a6ab7428ce Author: Jason Merrill Date: Thu Jun 23 23:14:35 2022 -0400 c++: dependent generic lambda template-id [PR106024] We were wrongly looking up the generic lambda op() in a dependent scope, and then trying to look up its instantiation at substitution time, but lambdas aren't instantiated, so we crashed. The fix is to not look into dependent class scopes. But this created trouble with wrongly trying to use a template from the enclosing scope when we aren't actually looking at a template-argument-list, in template/lookup18.C, so let's avoid that. PR c++/106024 gcc/cp/ChangeLog: * parser.cc (missing_template_diag): Factor out... (cp_parser_id_expression): ...from here. (cp_parser_lookup_name): Don't look in dependent object_type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-generic10.C: New test.
[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106024 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:07ac550393d00fcadcee21b44abee6bb30c93949 commit r13-1390-g07ac550393d00fcadcee21b44abee6bb30c93949 Author: Jason Merrill Date: Thu Jun 23 23:14:35 2022 -0400 c++: dependent generic lambda template-id [PR106024] We were wrongly looking up the generic lambda op() in a dependent scope, and then trying to look up its instantiation at substitution time, but lambdas aren't instantiated, so we crashed. The fix is to not look into dependent class scopes. But this created trouble with wrongly trying to use a template from the enclosing scope when we aren't actually looking at a template-argument-list, in template/lookup18.C, so let's avoid that. PR c++/106024 gcc/cp/ChangeLog: * parser.cc (missing_template_diag): Factor out... (cp_parser_id_expression): ...from here. (cp_parser_lookup_name): Don't look in dependent object_type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-generic10.C: New test.
[Bug analyzer/106000] RFE: -fanalyzer should complain about memory accesses that are definitely out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 David Malcolm changed: What|Removed |Added Summary|RFE: -fanalyzer should |RFE: -fanalyzer should |complain about definite |complain about memory |buffer overflows/underflows |accesses that are ||definitely out-of-bounds --- Comment #3 from David Malcolm --- "out-of-bounds" is more precise than "buffer overflow/underflow" so updating the title accordingly
[Bug rtl-optimization/106082] [13 Regression] Recent change broke m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106082 --- Comment #6 from Jeffrey A. Law --- And I'll confirm that m68k bootstrapped and regression tested. The various failures introduced by the 105231 change have all been fixed. Thanks.
[Bug target/106161] Dubious choice of optimization strategy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106161 --- Comment #3 from Victor Luchitz --- Compilation flags used: -c -std=c11 -g -m2 -mb -Os -fomit-frame-pointer -Wall -Wextra -pedantic -Wno-unused-parameter -Wimplicit-fallthrough=0 -Wno-missing-field-initializers -Wnonnull
[Bug target/106161] Dubious choice of optimization strategy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106161 --- Comment #2 from Victor Luchitz --- Created attachment 53234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53234=edit Test case Minimal test case. You can see in the disassembly the same pattern as described in the original report. First gcc tests for individual bitflags on the "actionbits" variable and stores results on the stack for each individual bitflag: 7c: 60 b3 mov r11,r0 7e: c9 10 and #16,r0 80: 1f 0e mov.l r0,@(56,r15) 82: 60 b3 mov r11,r0 84: c9 01 and #1,r0 86: 1f 0f mov.l r0,@(60,r15) Then performs tests after fetching them from memory: 112: 50 fd mov.l @(52,r15),r0 114: 20 08 tst r0,r0 116: 8f 01 bf.s11c <_R_SegLoop+0x11c> 118: 50 fe mov.l @(56,r15),r0 11a: 62 83 mov r8,r2 11c: 20 08 tst r0,r0 11e: 8f 02 bf.s126 <_R_SegLoop+0x126> It would make more sense to keep the value of 'actionbits' in a register and perform tst #imm,r0 instead.
[Bug target/106161] Dubious choice of optimization strategy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106161 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||sh --- Comment #1 from Richard Biener --- Can you provide a code snippet that can be actually compiled please?
[Bug tree-optimization/99918] [10/11/12/13 Regression] suboptimal code for bool bitfield tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
Franek Korta changed:
What|Removed |Added
CC||fkorta at gmail dot com
--- Comment #9 from Franek Korta ---
Another simple example:
#include
struct SomeClass {
bool cfg1 : 1;
bool cfg2 : 1;
bool cfg3 : 1;
bool check() const noexcept { return cfg1 || cfg2 || cfg3; }
};
bool check(const SomeClass& rt) {
return rt.check();
}
Emits:
check(SomeClass const&):
movzx edx, BYTE PTR [rdi]
mov eax, edx
and eax, 1
jne .L1
mov eax, edx
shr al
and eax, 1
je .L4
.L1:
ret
.L4:
mov eax, edx
shr al, 2
and eax, 1
ret
While it should:
check(SomeClass const&):
testbyte ptr [rdi], 7
setne al
ret
[Bug target/106161] New: Dubious choice of optimization strategy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106161
Bug ID: 106161
Summary: Dubious choice of optimization strategy
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vluchits at gmail dot com
Target Milestone: ---
Hello,
here's a piece of C code:
...
#define AC_NEWCEILING 16
#define AC_NEWFLOOR 32
...
if (newclipbounds)
{
int newfloorclipx = floorclipx;
int newceilingclipx = ceilingclipx;
uint16_t newclip;
// rewrite clipbounds
if (actionbits & AC_NEWFLOOR)
newfloorclipx = low;
if (actionbits & AC_NEWCEILING)
newceilingclipx = high;
newclip = (newceilingclipx << 8) + newfloorclipx;
clipbounds[x] = newclip;
newclipbounds[x] = newclip;
}
...
which is compiled with -Os and results in the following set of SH-2 assembler
instructions:
if (newclipbounds)
190: 54 fb mov.l @(44,r15),r4
192: 24 48 tst r4,r4
194: 8d 11 bt.s1ba <_R_SegLoop+0x1ba>
196: e0 58 mov #88,r0
if (actionbits & AC_NEWFLOOR)
198: 05 fe mov.l @(r0,r15),r5
19a: 25 58 tst r5,r5
19c: 8f 01 bf.s1a2 <_R_SegLoop+0x1a2>
19e: e0 5c mov #92,r0
floorclipx = ceilingclipx & 0x00ff;
1a0: 67 93 mov r9,r7
if (actionbits & AC_NEWCEILING)
1a2: 00 fe mov.l @(r0,r15),r0
1a4: 20 08 tst r0,r0
1a6: 8f 01 bf.s1ac <_R_SegLoop+0x1ac>
1a8: e0 40 mov #64,r0
int newceilingclipx = ceilingclipx;
1aa: 66 83 mov r8,r6
clipbounds[x] = newclip;
1ac: 00 fe mov.l @(r0,r15),r0
newclip = (newceilingclipx << 8) + newfloorclipx;
1ae: 46 18 shll8 r6
1b0: 37 6c add r6,r7
1b2: 67 7d extu.w r7,r7
clipbounds[x] = newclip;
1b4: 0c 75 mov.w r7,@(r0,r12)
newclipbounds[x] = newclip;
1b6: 50 fb mov.l @(44,r15),r0
1b8: 0c 75 mov.w r7,@(r0,r12)
What I find really odd is that gcc opts to cache results of bitwise AND on the
stack and reload them individually instead of simply doing tst #imm1,r0 and tst
#imm,r0. There are more instances of the this behavior further down the same
function.
Now memory reads are really expensive on the target architecture and I would
like to avoid them if possible. I'm not sure whether this behavior is triggered
by some optimization setting or is inherent to the architecture, but I'd
appreciate any help here.
[Bug c++/106046] GCC fails to disambiguate call to static member function when inside a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106046 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- thanks for the bug report, I think this is essentially a dup of PR105842 *** This bug has been marked as a duplicate of bug 105842 ***
[Bug c++/105842] rejects-valid: static member function overload set constrained by concepts for class template results in ambiguous call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105842 Patrick Palka changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #2 from Patrick Palka --- *** Bug 106046 has been marked as a duplicate of this bug. ***
[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104477 --- Comment #4 from Jonathan Wakely --- They are defined by the standard, as library traits. The intrinsics are needed to implement what the standard defines.
[Bug ada/106037] ICE with Aggregate aspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-07-01 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- On mainline: +===GNAT BUG DETECTED==+ | 13.0.0 20220701 (experimental) [master bb6325c8ad2] (x86_64-suse-linux) | | Assert_Failure failed precondition from sinfo-nodes.ads:3970
[Bug rtl-optimization/106160] New: invariant motion DF RD problem invokes quadratic behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106160 Bug ID: 106160 Summary: invariant motion DF RD problem invokes quadratic behavior Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- RTL invariant motion uses local DF analysis and a RD problem which in turn calls df_maybe_reorganize_def_refs which does work for all pseudos in a function. It doesn't work to conditionalize this on !df->analyze_subset since appearantly RD relies on this ordering somewhere.
[Bug ada/106031] ICE on container map empty aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106031 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-07-01 --- Comment #1 from Eric Botcazou --- Confirmed, but probably illegal since you use Empty to declare itself.
[Bug c++/106159] New: Have -Woverloaded-virtual not warn about virtual destructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106159 Bug ID: 106159 Summary: Have -Woverloaded-virtual not warn about virtual destructors? Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: adl at gnu dot org Target Milestone: --- The new version of -Woverloaded-virtual recently introduced seems to warn about virtual destructors in case of multiple inheritance. Is this really intended? Could destructors be ignored from this warning? Also note that the diagnostic is output three times. $ cat > vee.cc
[Bug ipa/106158] IPA SRA ssa_name_only_returned_p is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158 --- Comment #2 from Richard Biener --- That is with -O2 -funswitch-loops -fno-thread-jumps -fno-tree-dominator-opts -fno-tree-vrp plus some changes to make unswitching SSA update cheaper
[Bug ipa/106158] IPA SRA ssa_name_only_returned_p is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158 --- Comment #1 from Richard Biener --- ipa SRA: 56.58 ( 28%) 0.00 ( 0%) 56.60 ( 28%) 552 ( 0%)
[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 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- Revert the commit for now...and I am figure out how to resolve this: lp64 target will have 2 warnings: 22:7: warning: array subscript 0 is outside array bounds of 'void [0]' [-Warray-bounds] 19:51: note: object of size 0 allocated by 'operator new []' 22:7: warning: 'void* __builtin_memset(void*, int, long unsigned int)' offset [0, 3] is out of the bounds [0, 0] [-Warray-bounds] ilp32 target will have only 1 warning: 22:7: warning: array subscript 0 is outside array bounds of 'void [0]' [-Warray-bounds] 19:51: note: object of size 0 allocated by 'operator new []'
[Bug ipa/106158] New: IPA SRA ssa_name_only_returned_p is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106158
Bug ID: 106158
Summary: IPA SRA ssa_name_only_returned_p is quadratic
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
If you take a function like
unsigned bar (int);
unsigned foo (int flag)
{
unsigned val = 0;
#define DOIT \
for (int i = 0; i < 2048; ++i) \
if (flag) \
val ^= bar (i);
#define DOIT10 DOIT DOIT DOIT DOIT DOIT DOIT DOIT DOIT DOIT DOIT
#define DOIT100 DOIT10 DOIT10 DOIT10 DOIT10 DOIT10 DOIT10 DOIT10 DOIT10 DOIT10
DOIT10
#define DOIT1000 DOIT100 DOIT100 DOIT100 DOIT100 DOIT100 DOIT100 DOIT100
DOIT100 DOIT100 DOIT100
#define DOIT1 DOIT1000 DOIT1000 DOIT1000 DOIT1000 DOIT1000 DOIT1000
DOIT1000 DOIT1000 DOIT1000 DOIT1000
DOIT1000
DOIT1000
DOIT1000
DOIT1000
return val;
}
then you'll see that ssa_name_only_returned_p is eventually called for each
return value of bar () but they are chained together via the ^= stmts.
While there's a bitmap to avoid exponential behavior the actual result
is not cached nor used across different SSA name def chain analyses.
It might be cheaper to walk use->def links from all return stmts somehow
but caching would also fix this particular case.
[Bug tree-optimization/106157] New: ICE verify_ssa failed since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
Bug ID: 106157
Summary: ICE verify_ssa failed since r13-1268-g8c99e307b20c502e
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: aldyh at redhat dot com, amacleod at redhat dot com
Target Milestone: ---
The following crashes:
$ cat 1.ii
namespace ffmpegthumbnailer {
struct VideoFrame {
unsigned lineSize;
void *xxx;
};
} // namespace ffmpegthumbnailer
class QString;
class QImage;
namespace ffmpegthumbnailer {
struct VideoThumbnailer {
void generateThumbnail(const QString &, QImage &);
int m_ThumbnailSize;
bool m_MaintainAspectRatio;
};
struct MovieDecoder {
void getScaledVideoFrame(int, bool, VideoFrame &);
};
void VideoThumbnailer::generateThumbnail(const QString &, QImage &) {
MovieDecoder movieDecoder;
VideoFrame videoFrame;
movieDecoder.getScaledVideoFrame(m_ThumbnailSize, m_MaintainAspectRatio,
videoFrame);
}
} // namespace ffmpegthumbnailer
class QString;
class QImage;
namespace ffmpegthumbnailer {
} // namespace ffmpegthumbnailer
struct FFMpegThumbnailer {
bool create(const QString &, QImage &);
ffmpegthumbnailer::VideoThumbnailer m_Thumbnailer;
};
__attribute__((visibility("default"))) bool
FFMpegThumbnailer::create(const QString , QImage ) {
m_Thumbnailer.generateThumbnail(path, img);
}
$ cat 2.ii
void __throw_length_error(char);
struct __is_integer {
enum { __value = 1 };
};
struct __is_integer_nonstrict : __is_integer {
enum { __width = __value ? sizeof(long) * 8 : 0 };
};
struct __numeric_traits_integer {
static const int __digits = __is_integer_nonstrict::__width - 1;
static const long __max = 1 ? (((long)1 << __digits - 1) - 1 << 1) + 1 : 0;
};
template
void __fill_a(_FIte __first, _FIte __last, _Tp &__value) {
if (long __len = __last - __first)
__builtin_memset(__first, __value, __len);
}
template
void fill_n(_OI __first, _Size __n, _Tp __value) {
__fill_a(__first, __first + __n, __value);
}
template struct allocator;
template struct allocator_traits;
template struct allocator_traits> {
using pointer = _Tp *;
};
struct __alloc_traits : allocator_traits> {};
template
void __uninitialized_default_n_a(_ForwardIterator __first, _Size __n, _Tp) {
typename __val = *++__first;
fill_n(__first, __n - 1, __val);
}
struct _Vector_base {
struct {
__alloc_traits::pointer _M_start;
__alloc_traits::pointer _M_finish;
} _M_impl;
__alloc_traits::pointer _M_allocate(long);
};
template struct vector : _Vector_base {
void resize(unsigned long __new_size) {
long __trans_tmp_5, __trans_tmp_4(_M_impl._M_finish - _M_impl._M_start);
if (__new_size > __trans_tmp_4) {
__trans_tmp_5 = _M_impl._M_finish - _M_impl._M_start;
_M_default_append(__new_size - __trans_tmp_5);
}
}
void clear() {
__alloc_traits::pointer __pos = _M_impl._M_start;
if (_M_impl._M_finish - _M_impl._M_start)
_M_impl._M_finish = __pos;
}
void _M_default_append(unsigned long);
};
template void vector<_Tp>::_M_default_append(unsigned long __n)
{
long __trans_tmp_12, __trans_tmp_9(_M_impl._M_finish - _M_impl._M_start),
__navail;
unsigned long __diffmax = __numeric_traits_integer::__max;
if (__trans_tmp_9 > __diffmax - __trans_tmp_9)
;
if (__navail) {
long __trans_tmp_8(_M_impl._M_finish - _M_impl._M_start);
if (__diffmax - __trans_tmp_8 < __n)
__throw_length_error(0);
__alloc_traits::pointer __new_start(_M_allocate(__trans_tmp_12));
char __trans_tmp_2;
__uninitialized_default_n_a(__new_start, __n, __trans_tmp_2);
}
}
namespace ffmpegthumbnailer {
struct VideoFrame {
unsigned lineSize;
vector frameData;
};
struct MovieDecoder {
void getScaledVideoFrame(int, bool, VideoFrame &);
};
void MovieDecoder::getScaledVideoFrame(int, bool, VideoFrame ) {
videoFrame.frameData.clear();
videoFrame.frameData.resize(videoFrame.lineSize);
}
} // namespace ffmpegthumbnailer
$ g++ -flto=auto -O2 -shared 1.ii 2.ii -fPIC -fvisibility=hidden -w
1.ii: In member function ‘create’:
1.ii:39:1: error: definition in block 5 does not dominate use in block 6
39 | FFMpegThumbnailer::create(const QString , QImage ) {
| ^
for SSA_NAME: _31 in statement:
_12 = _31;
during GIMPLE pass: dom
1.ii:39:1: internal compiler error: verify_ssa failed
0x106cfdd verify_ssa(bool, bool)
/home/marxin/Programming/gcc/gcc/tree-ssa.cc:1211
0xd29c58 execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2098
0xd2a0ba execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any
[Bug tree-optimization/106157] [13 Regression] ICE verify_ssa failed since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 Ever confirmed|0 |1 Summary|ICE verify_ssa failed since |[13 Regression] ICE |r13-1268-g8c99e307b20c502e |verify_ssa failed since ||r13-1268-g8c99e307b20c502e Last reconfirmed||2022-07-01
[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106144
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e52592073f6df3d7a3acd9f0436dcc32a8b7493d
commit r13-1381-ge52592073f6df3d7a3acd9f0436dcc32a8b7493d
Author: Jakub Jelinek
Date: Fri Jul 1 11:17:41 2022 +0200
wide-int: Fix up wi::shifted_mask [PR106144]
As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec
128,
while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2
and prec 128.
The problem is that the code is written with the assumption that there are
3 bit blocks (or 2 if start is 0), but doesn't consider the possibility
where there are 2 bit blocks (or 1 if start is 0) where the highest block
isn't present. In that case, there is the optional block of negate ? 0 :
-1
elts, followed by just one elt (either one from the if (shift) or just
negate ? -1 : 0) and the rest is implicit sign-extension.
Only if end < prec there is 1 or more bits above it that have different bit
value and so we need to emit all the elts till end and then one more elt.
if (end == prec) would work too, because we have:
if (width > prec - start)
width = prec - start;
unsigned int end = start + width;
so end is guaranteed to be end <= prec, dunno what is preferred.
2022-07-01 Jakub Jelinek
PR middle-end/106144
* wide-int.cc (wi::shifted_mask): If end >= prec, return right
after
emitting element for shift or if shift is 0 first element after
start.
(wide_int_cc_tests): Add tests for equivalency of wi::mask and
wi::shifted_mask with 0 start.
[Bug bootstrap/106145] [12/13 Regression] /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106145 --- Comment #2 from Matthias Klose --- also reported as https://sourceware.org/bugzilla/show_bug.cgi?id=29310
[Bug target/106122] [12/13 Regression] ICE in fixup_args_size_notes, at expr.cc:4493 since r12-6106-gef26c151c14a8717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106122
--- Comment #3 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:17419b61edd350147b0cc10c3da0b8461e51a42c
commit r13-1380-g17419b61edd350147b0cc10c3da0b8461e51a42c
Author: Roger Sayle
Date: Fri Jul 1 09:18:07 2022 +0100
PR target/106122: Don't update %esp via the stack with -Oz on x86.
When optimizing for size with -Oz, setting a register can be minimized by
pushing an immediate value to the stack and popping it to the destination.
Alas the one general register that shouldn't be updated via the stack is
the stack pointer itself, where "pop %esp" can't be represented in GCC's
RTL ("use of a register mentioned in pre_inc, pre_dec, post_inc or
post_dec is not permitted within the same instruction"). This patch
fixes PR target/106122 by explicitly checking for SP_REG in the
problematic peephole2.
2022-07-01 Roger Sayle
gcc/ChangeLog
PR target/106122
* config/i386/i386.md (peephole2): Avoid generating pop %esp
when optimizing for size.
gcc/testsuite/ChangeLog
PR target/106122
* gcc.target/i386/pr106122.c: New test case.
[Bug other/100695] Format decoder, quoting in 'dump_printf' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100695
--- Comment #2 from Tobias Burnus ---
Created attachment 53233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53233=edit
Patch which does not work (segfault during self test) – but maybe it gives an
idea how to solve the issue
I think there are multiple issues:
(a) '%T' does not accept %qT but there is still an error for using %<%T%>
(b) Using %qT should be accepted. This implies both the addition of "q" to
c-family/c-format.cc's gcc_dump_printf_char_table
to permit it.
(c) Using %qT kind of works - but does not actually print the quotes.
(cf. comment 1)
That's because of how it is processed. In pretty-print.cc pp_format:
if (quote)
pp_begin_quote (pp, pp_show_color (pp));
...
ok = pp_format_decoder (pp) (pp, text, p,
precision, wide, plus, hash, ,
formatters[argno]);
...
if (quote)
pp_end_quote (pp, pp_show_color (pp));
This works well, if the item - is processed directly.
For instance, tree-diagnostic.cc's default_tree_printer just does:
case 'E':
...
pp_identifier (pp, IDENTIFIER_POINTER (t));
return true;
However, in dumpfile.cc's dump_pretty_printer::decode_format there is no direct
output but the %qT processing is deferred (spec = 'T', buffer_ptr = "qT"):
dump_pretty_printer::decode_format (text_info *text, const char *spec,
const char **buffer_ptr)
{
/* Various format codes that imply making an optinfo_item and stashed it
for later use (to capture metadata, rather than plain text). */
...
case 'T':
{
tree t = va_arg (*text->args_ptr, tree);
/* Make an item for the tree, and stash it. */
optinfo_item *item = make_item_for_dump_generic_expr (t, TDF_SLIM);
stash_item (buffer_ptr, item);
return true;
And the 'stash_item' effectively undoes the quote. For %<...%>, those are
processed separately, such that 'decode_format' only processes '%T' and the
quotes are retained.
Thus, one way would be to 'obstack_grow' - or something like that to "split"
'q' ... 'T' in %qT. Or to handle somehow the
pp_buffer(pp)
in dump_pretty_printer::decode_format
[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106144 --- Comment #3 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #2) > Created attachment 53228 [details] > gcc13-pr106144.patch > > Untested fix. Thanks.
[Bug middle-end/105874] [13 Regression] Incorrect codegen and ICE since g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874 --- Comment #10 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:90129d39ca0fc1d2ac9cf960379feccea878bd90 commit r13-1378-g90129d39ca0fc1d2ac9cf960379feccea878bd90 Author: Eric Botcazou Date: Fri Jul 1 09:59:05 2022 +0200 Amend fix for PR middle-end/105874 The original fix is very likely too big a hammer. gcc/ PR middle-end/105874 * expr.cc (expand_expr_real_1) : Force EXPAND_MEMORY for the expansion of the inner reference only in the usual cases where a memory reference is required.
[Bug bootstrap/106156] [13 Regression] libtool fails to link liblto_plugin.la on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106156 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-07-01 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Yep, I've also noticed that and hope it gets fixed with g:51debf7f857dddfb4dd2493867d2648041e7d8de.
[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106126 --- Comment #19 from David Binderman --- Created attachment 53232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53232=edit gzipped C++ source code I have a third test case. I suspect it is a duplicate of #2, but could I ask you to confirm this, please ? It is part of the same package as #2, wxWidgets.
[Bug bootstrap/106156] [13 Regression] libtool fails to link liblto_plugin.la on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106156 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org Target Milestone|--- |13.0 --- Comment #1 from Richard Biener --- probably caused by the -pthread change
[Bug lto/106118] lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106118 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Martin Liška --- Should be fixed now.
[Bug lto/106118] lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106118 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:51debf7f857dddfb4dd2493867d2648041e7d8de commit r13-1377-g51debf7f857dddfb4dd2493867d2648041e7d8de Author: Pekka Seppänen Date: Tue Jun 28 17:14:09 2022 +0300 lto: pass -pthread to AM_LDFLAGS [PR 106118] Move -pthread from configure.ac to Makefile.in so that it is passed to AM_LDFLAGS. PR lto/106118 lto-plugin/ChangeLog: * configure.ac: Move -pthread from here... * Makefile.am: ...to here. * configure: Regenerate. * Makefile.in: Likewise.
[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106153 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #7 from Richard Biener --- .
[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 Target Milestone|--- |13.0
[Bug bootstrap/106145] [12/13 Regression] /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106145 Richard Biener changed: What|Removed |Added Keywords||build Target Milestone|--- |12.2
[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106131 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9701432ff79926a5dd3303be3417e0bd0c24140b commit r13-1376-g9701432ff79926a5dd3303be3417e0bd0c24140b Author: Richard Biener Date: Thu Jun 30 10:33:40 2022 +0200 tree-optimization/106131 - wrong code with FRE rewriting The following makes sure to not use the original TBAA type for looking up a value across an aggregate copy when we had to offset the read. 2022-06-30 Richard Biener PR tree-optimization/106131 * tree-ssa-sccvn.cc (vn_reference_lookup_3): Force alias-set zero when offsetting the read looking through an aggregate copy. * g++.dg/torture/pr106131.C: New testcase.
[Bug tree-optimization/106131] [10/11/12 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106131 Richard Biener changed: What|Removed |Added Known to work||13.0 Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |-fstrict-aliasing breaks|-fstrict-aliasing breaks |normal program that does|normal program that does |not use any pointer or |not use any pointer or |reference |reference --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106126 --- Comment #18 from Martin Liška --- (In reply to David Binderman from comment #15) > Created attachment 53230 [details] > gzipped C++ source code > > > Please find attached an additional C++ test case. -O3 required this time: > > $ /home/dcb/gcc/results/bin/g++ -c -O3 q1.ii > during GIMPLE pass: iftoswitch > ../src/common/uri.cpp: In member function ‘const char* > wxURI::ParseUserInfo(const char*)’: > ../src/common/uri.cpp:1086:1: internal compiler error: Segmentation fault > 0x10ba099 crash_signal(int) > ../../trunk.git/gcc/toplev.cc:322 > 0x134244a gimple_nop_p(gimple const*) > ../../trunk.git/gcc/gimple.h:6747 > 0x134244a verify_use(basic_block_def*, basic_block_def*, ssa_use_operand_t*, > gimple*, bool, bitmap_head*) > ../../trunk.git/gcc/tree-ssa.cc:880 I've just verified the following test-case is resolved fine with the current master.
[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106126 Martin Liška changed: What|Removed |Added Summary|[12 Regression] tree check |[13 Regression] tree check |fail in |fail in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:87 since |at gimple-expr.cc:87 since |r13-1184-g57424087e82db140 |r13-1184-g57424087e82db140 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Martin Liška --- Fixed now.
[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106126 --- Comment #16 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:618bac5b486832edd3f8eb3ada74740e389dfcb8 commit r13-1375-g618bac5b486832edd3f8eb3ada74740e389dfcb8 Author: Martin Liska Date: Thu Jun 30 15:00:17 2022 +0200 if-to-switch: properly allow side effects only for first condition Properly allow side effects only for a first BB in a condition chain. PR tree-optimization/106126 gcc/ChangeLog: * gimple-if-to-switch.cc (struct condition_info): Save has_side_effect. (find_conditions): Parse all BBs. (pass_if_to_switch::execute): Allow only side effects for first BB. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr106126.c: New test.
[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106150 --- Comment #6 from Jens Maurer --- Related clang bug: https://github.com/llvm/llvm-project/issues/56313
