[Bug c++/83756] gcc (mingw64) 7.2.0 ICE in gimplify_expr on boost::call_once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-12-02
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #10 from Andrew Pinski ---
This is not the best reduced testcase because the original one was accepted
without -fms-extensions.
template
auto invoke(Fp && f, A0 && a0) -> decltype(*(a0).*f)
{
return (*(a0)).*f;
}
struct A{void doB(); };
void g()
{
A a;
invoke(::doB, );
}
CUT
Let me find one which is accepted with -fms-extensions.
[Bug c++/83756] gcc (mingw64) 7.2.0 ICE in gimplify_expr on boost::call_once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > This is a pointer to member function with -fms-extensions issue. > > I am reducing, the ICE can still be seen on the trunk. I should mention I was able to reproduce the failure on x86_64-linux even though the testcase needed some changes to get the failure there.
[Bug c++/83756] gcc (mingw64) 7.2.0 ICE in gimplify_expr on boost::call_once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756 Andrew Pinski changed: What|Removed |Added Keywords|needs-reduction | --- Comment #8 from Andrew Pinski --- This is a pointer to member function with -fms-extensions issue. I am reducing, the ICE can still be seen on the trunk.
[Bug tree-optimization/103300] [12 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-4526-gd8edfadfc7a9795b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103300
--- Comment #6 from Zhendong Su ---
Another test likely for the same issue:
[652] % gcctk -O3 small.c; ./a.out
Aborted
[653] % gcctk -O2 -floop-unroll-and-jam small.c; ./a.out
Aborted
[654] % cat small.c
int printf(const char *, ...);
int a[2], b, c, d, e;
int main() {
if (b) {
printf("0");
goto L2;
}
L1:
b = 0;
L2:
if (d)
L3:
goto L1;
if (e)
goto L3;
if (c)
goto L2;
for (b = 0; b < 3; b++)
for (d = 0; d < 2; d++)
a[d] ^= 1;
if (a[1] != 1)
__builtin_abort();
return 0;
}
[Bug c++/72809] ICE on x86_64-linux-gnu (Segmentation fault, tree_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72809 Andrew Pinski changed: What|Removed |Added CC||rmx12133 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 81321 has been marked as a duplicate of this bug. ***
[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81321
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #7 from Andrew Pinski ---
Yes it is the same.
Reduced testcase:
typedef __builtin_va_list __gnuc_va_list;
namespace std {
class type_info {};
}
template
void f(t)
{
typeid(t);
}
typedef __gnuc_va_list va_list;
void calla(::va_list l) {
f(l);
}
*** This bug has been marked as a duplicate of bug 72809 ***
[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81321 Andrew Pinski changed: What|Removed |Added Keywords|needs-bisection | --- Comment #6 from Andrew Pinski --- I almost positive it is the same issue as PR 72809 (though using typeinfo instead of throw).
[Bug target/103525] [RISCV] wrong function entry with -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103525 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||kito at gcc dot gnu.org Last reconfirmed||2021-12-02 --- Comment #1 from Kito Cheng --- Confirmed, but I suspect it's binutils bugs, I've forward bug to Nelson Chu (RISC-V binutils maintainer)
[Bug c++/72809] ICE on x86_64-linux-gnu (Segmentation fault, tree_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72809 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |7.0
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #8 from Zdenek Sojka --- Created attachment 51917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51917=edit testcase failing with the patch applied The attached unreduced testcase is failing with the patch applied, but is OK without the patch: $ /repo/gcc-trunk/binary-trunk-r12-5705-20211202014655-g1c5317d6214-checking-yes-rtl-df-extra-pr103149-riscv64/bin/riscv64-unknown-linux-gnu-gcc -O3 -fharden-compares -fno-toplevel-reorder -fno-tree-fre -fno-tree-vrp -funroll-all-loops xxx.c -static -w $ qemu-riscv64 -- ./a.out Trace/breakpoint trap
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #7 from Zdenek Sojka --- (In reply to Alexandre Oliva from comment #6) > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585963.html appears > to no longer hit this error, though I've only inspected the asm output, not > tried to run it yet; can anyone confirm? Thank you for the patch. Compiling the testcase with a patched compiler fixes this issue for me (using userspace qemu emulation). The asm diff is too big, due to different register allocation and stack offsets, for me to quickly tell what exactly changes on the asm level.
[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81321 Andrew Pinski changed: What|Removed |Added Keywords|needs-reduction | --- Comment #5 from Andrew Pinski --- Reducing ...
[Bug c++/81321] Segmentation fault - va_list boost_any - gcc5.4.0 - gcc-snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81321 Andrew Pinski changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code, ||needs-bisection, ||needs-reduction Known to fail||4.9.4, 5.4.0, 6.1.0, 6.4.0 Known to work||7.1.0 --- Comment #4 from Andrew Pinski --- Looks to be fixed in GCC 7.1.0+
[Bug c++/80521] Wrong line reported in error for missing template argument in friend class declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80521
--- Comment #3 from Andrew Pinski ---
The first testcase produces:
:41:8: error: 'ProducerAccess' is not a template
41 | struct ProducerAccess {
|^~
:14:16: note: previous declaration here
14 | friend class ProducerAccess;
|^~
Which is exactly what you expect.
[Bug c++/80521] Wrong line reported in error for missing template argument in friend class declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80521 --- Comment #2 from Andrew Pinski --- Both testcases seems to be fixed in GCC 9+.
[Bug c++/80427] DR1658 is implemented in C++03 and C++14 mode, but not C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80427 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-04-18 00:00:00 |2021-12-1 Keywords||rejects-valid --- Comment #2 from Andrew Pinski --- DR1658 is marked as Status: C++14.
[Bug c++/103518] g++ hangs on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103518 --- Comment #4 from Egor Pugin --- Created attachment 51916 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51916=edit preprocessed file
[Bug c++/59950] [9/10/11/12 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/59950] [9/10/11/12 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 --- Comment #4 from Andrew Pinski --- (In reply to Martin Sebor from comment #2) > The current top of 6.0 trunk still issues the bogus diagnostic. Confirming > also with prior versions. Actually this example is invalid code as DR 1312 (which was recorded as PR 79832, see that bug for it was fixed in GCC 9+).
[Bug c++/59950] [9/10/11/12 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 --- Comment #3 from Andrew Pinski --- (In reply to Martin Sebor from comment #2) > The current top of 6.0 trunk still issues the bogus diagnostic. Confirming > also with prior versions. Note this example is different as it worked in 4.6.4 but the first example failed in 4.6.4.
[Bug c++/84151] [6 Regression] g++ generates two identical loads in a volatile-qualified member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84151 Andrew Pinski changed: What|Removed |Added CC||deaeod at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 70091 has been marked as a duplicate of this bug. ***
[Bug c++/70091] C++ frontend emits dead volatile copy on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70091 Andrew Pinski changed: What|Removed |Added Known to work||4.8.5 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84686 Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 84151. vol.0 = *this; *** This bug has been marked as a duplicate of bug 84151 ***
[Bug analyzer/103526] New: -fanalyzer considers memcpy()ed and returned pointer to malloc()ed memory a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103526
Bug ID: 103526
Summary: -fanalyzer considers memcpy()ed and returned pointer
to malloc()ed memory a memory leak
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: guilherme.janczak at yandex dot com
Target Milestone: ---
Created attachment 51915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51915=edit
The preprocessed file output by '$ egcc -v -save-temps -fanalyzer example.c'
I found this while trying -fanalyzer on my hangman game. The attached
preprocessed file comes from the "example.c" file as requested by the bug
writing guidelines.
It seems that my allocator function game_new() triggers a bug. It creates a
struct game_state in the stack with the identifier 'tmp', as well as a pointer
to the same kind of struct with the identifier 'rval'. It assigns the return
value of malloc() to a member of 'tmp', then it allocates storage for 'rval',
and then it memcpy()es 'tmp' into the storage 'rval' points to and returns
'rval'.
GCC's static analyzer seems to think the pointer inside 'tmp' leaks at the end
of the function because it's not smart enough to realize it has been returned
through 'rval'.
Here's the file "example.c" which triggers this bug:
#include
#include
struct game_state {
const char *word; /* This is a pointer to static storage. */
char *word_state;
};
const char *const teststr = "test string";
static struct game_state *game_new(void);
static void game_free(struct game_state *);
int
main(void)
{
struct game_state *game;
if ((game = game_new()) == NULL)
exit(1);
game_free(game);
exit(0);
}
static struct game_state *
game_new(void)
{
struct game_state tmp = {0};
struct game_state *rval = NULL;
size_t wordlen;
tmp.word = teststr;
wordlen = strlen(tmp.word);
if ((tmp.word_state = malloc(wordlen+1)) == NULL)
goto err;
if ((rval = malloc(sizeof(*rval))) == NULL)
goto err;
memcpy(rval, , sizeof(*rval));
return (rval);
err:
free(tmp.word_state);
free(rval);
return (NULL);
}
static void
game_free(struct game_state *game)
{
if (game == NULL)
return;
free(game->word_state);
free(game);
}
$ egcc -v -save-temps -fanalyzer example.c
Using built-in specs.
COLLECT_GCC=egcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd7.0/11.2.0/lto-wrapper
Target: x86_64-unknown-openbsd7.0
Configured with: /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/configure
--with-stage1-ldflags=-L/usr/obj/ports/gcc-11.2.0/bootstrap/lib --verbose
--program-transform-name='s,^,e,' --disable-nls --with-system-zlib
--disable-libmudflap --disable-libgomp --disable-libssp --disable-tls
--with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t
--with-gmp=/usr/local --enable-languages=c,c++,fortran,objc,ada,d
--disable-libstdcxx-pch --enable-default-ssp --enable-default-pie --without-isl
--enable-cpp --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man
--infodir=/usr/local/info --localstatedir=/var --disable-silent-rules
--disable-gtk-doc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fanalyzer' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/local/libexec/gcc/x86_64-unknown-openbsd7.0/11.2.0/cc1 -E -quiet -v
example.c -mtune=generic -march=x86-64 -fanalyzer -fpch-preprocess -o
a-example.i
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-openbsd7.0/11.2.0/../../../../x86_64-unknown-openbsd7.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-unknown-openbsd7.0/11.2.0/include
/usr/local/lib/gcc/x86_64-unknown-openbsd7.0/11.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fanalyzer' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/local/libexec/gcc/x86_64-unknown-openbsd7.0/11.2.0/cc1 -fpreprocessed
a-example.i -quiet -dumpdir a- -dumpbase example.c -dumpbase-ext .c
-mtune=generic -march=x86-64 -version -fanalyzer -o a-example.s
GNU C17 (GCC) version 11.2.0 (x86_64-unknown-openbsd7.0)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.2.0 (x86_64-unknown-openbsd7.0)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b55fd2c5b9d1ebf92b67661bceac5878
[Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510 --- Comment #3 from Andrew Pinski --- The only registers which are saved are the callee saved register IIRC. So you need to know the ABI.
[Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103510 --- Comment #2 from Andrew Pinski --- Funny there is a comment in the libgcc sources: /* This will segfault if the register hasn't been saved. */ Which has been there since day 1 of IA-64 ABI exception handling back in g:52a11cbfcf0cfb32628b6953588b6af4037ac0b6
[Bug demangler/103525] New: [RISCV] wrong function entry with -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103525
Bug ID: 103525
Summary: [RISCV] wrong function entry with
-fpatchable-function-entry
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: wcohen at redhat dot com
Target Milestone: ---
Created attachment 51914
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51914=edit
Reproducer to show DW_AT_low_pc doesn't always match label for function entry.
When the riscv linux kernel was compiled with CONFIG_DYNAMIC_FTRACE=y the
addresses listed in DW_AT_low_pc in the debuginfo and the /proc/kallsyms did
not match. The difference was 0x10 bytes. The /proc/kallsyms entry would
point to the function label and the DW_AT_low_pc in the DIE for the function
would point to the first instruction after the 8 nop instructions created by
the -fpatchable-function-entry=8 enable by the CONFIG_DYNAMIC_FTRACE=y. This
seems to be similar to pr99217 for mips.
Can demonstrate the problem with gcc-10.3.1 with the small reproducer
u32_test.c:
$ rpm -q gcc
gcc-10.3.1-1.fc33.riscv64
$ gcc -fpatchable-function-entry=8 -g -O2 -save-temps u32_test.c -o u32_test
$ llvm-dwarfdump --name="main" u32_test
u32_test: file format elf64-littleriscv
0x00cf: DW_TAG_subprogram
DW_AT_external(true)
DW_AT_name("main")
DW_AT_decl_file ("/home/riscv/u32_test.c")
DW_AT_decl_line (8)
DW_AT_decl_column (0x01)
DW_AT_prototyped (true)
DW_AT_type(0x0030 "int")
DW_AT_low_pc (0x000103f0)
DW_AT_high_pc (0x0001040a)
DW_AT_frame_base (DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites (true)
DW_AT_sibling (0x013c)
$ nm u32_test |grep main
U __libc_start_main@@GLIBC_2.27
000103e0 T main
$gcc -g -O2 -save-temps u32_test.c -o u32_test
$ llvm-dwarfdump --name="main" u32_test
u32_test: file format elf64-littleriscv
0x00cf: DW_TAG_subprogram
DW_AT_external(true)
DW_AT_name("main")
DW_AT_decl_file ("/home/riscv/u32_test.c")
DW_AT_decl_line (8)
DW_AT_decl_column (0x01)
DW_AT_prototyped (true)
DW_AT_type(0x0030 "int")
DW_AT_low_pc (0x000103e0)
DW_AT_high_pc (0x000103fa)
DW_AT_frame_base (DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites (true)
DW_AT_sibling (0x013c)
$ nm u32_test |grep main
U __libc_start_main@@GLIBC_2.27
000103e0 T main
[Bug target/103383] Microblaze bswaphi2 can cause issues with delay slots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 --- Comment #6 from Rich Kujoth --- I'm not really in a position to change toolchains, so I needed to make it work with the version of GCC I have. Since the issue is specific to swap16, I made my own swap16 function that explicitly calls the two microblaze instructions, rather than using the GCC built-in. This resolves the issue and I don't see any instances of swapb/swaph following a delayed branch in the compiled code.
[Bug c++/49952] [C++0x] Unicode literals do not generate errors as prescribed by the FDIS standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49952 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-02 Keywords||diagnostic Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- With -std=c++20, we do warn: :2:21: warning: \U7FFF is outside the UCS codespace 2 | char32_t s[] = U"\U0010\U7FFF"; | ^~~ This warning was implemented in r10-3414-g0900e29cdbc5. I wonder if we should just enable it for all C++ standards and above of C++20+.
[Bug c++/103518] g++ hangs on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103518 --- Comment #3 from Andrew Pinski --- (In reply to Egor Pugin from comment #0) > Preprocessed file (315KB): > https://www.dropbox.com/s/tey8z9mfi123uon/gcc_hang.tar.xz?dl=1 Can you attach this? It should be under the size limit.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/103524] New: [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug ID: 103524 Summary: [meta-bug] modules issue Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, meta-bug Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- A bug to keep track of modules issue, the number have grown a lot recently.
[Bug testsuite/103522] New test case gcc.dg/ubsan/pr103456.c fails in r12-5649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103522 Siddhesh Poyarekar changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-12-02 --- Comment #1 from Siddhesh Poyarekar --- OK I see it on x86_64 too and seems to be specific to executing from ubsan.exp instead of dg.exp. So the tree-objsz dump file does not seem to get generated when -flto is present, presumably because the pass gets skipped? The test needs to be skipped in this case.
[Bug target/103302] wrong code with -fharden-compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302 --- Comment #6 from Alexandre Oliva --- https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585963.html appears to no longer hit this error, though I've only inspected the asm output, not tried to run it yet; can anyone confirm?
[Bug tree-optimization/103523] [11/12 Regression] SVE float auto-vect float format expand failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
void d(float *a, float b, int c) {
float e;
for (; c; c--, e += b)
a[c] = e;
}
[Bug target/103515] Unexpected OPTION_MASK_SAVE_TOC_INDIRECT of rs6000_isa_flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC||jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Kewen Lin --- Note that if we changed the pragma syntax by attribute syntax, the ICE would be gone.
[Bug target/103515] Unexpected OPTION_MASK_SAVE_TOC_INDIRECT of rs6000_isa_flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103515
--- Comment #2 from Kewen Lin ---
Here I assumed that the current cl optimization/option save and restore scheme
wants to keep the global_option/global_option_set same as the one from the
initial option processing. After we parsing all attributes/pragmas, we can
expect the rs6000_isa_flags back to the default one.
The fix seems to require us to take this OPTION_MASK_SAVE_TOC_INDIRECT as one
option which would be affected by optimize level.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 327822e5357..f9ee7044889 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -3478,6 +3478,16 @@ rs6000_override_options_after_change (void)
}
else if (!OPTION_SET_P (flag_cunroll_grow_size))
flag_cunroll_grow_size = flag_peel_loops || optimize >= 3;
+ /* If we can shrink-wrap the TOC register save separately, then use
+ -msave-toc-indirect unless explicitly disabled. */
+ if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
+ && flag_shrink_wrap_separate
+ && optimize_function_for_speed_p (cfun))
+rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT;
+ else
+rs6000_isa_flags &= ~OPTION_MASK_SAVE_TOC_INDIRECT;
Also require us to build one target_node when we are going to save one new
optimization_node which isn't the same as the default one, since at that time
the optimization level changes and the option is possible to be changed as
well.
diff --git a/gcc/attribs.c b/gcc/attribs.c
index c252f5af07b..3382c095fa8 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -607,7 +607,14 @@ decl_attributes (tree *node, tree attributes, int flags,
if (TREE_CODE (*node) == FUNCTION_DECL
&& optimization_current_node != optimization_default_node
&& !DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node))
-DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) = optimization_current_node;
+{
+ DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) = optimization_current_node;
+ tree target_node
+= build_target_option_node (_options, _options_set);
+ if (!DECL_FUNCTION_SPECIFIC_TARGET (*node)
+ && target_node != target_option_default_node)
+DECL_FUNCTION_SPECIFIC_TARGET (*node) = target_node;
+}
/* If this is a function and the user used #pragma GCC target, add the
options to the attribute((target(...))) list. */
[Bug tree-optimization/103523] [11/12 Regression] SVE float auto-vect float format expand failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-02 Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever confirmed|0 |1 Target Milestone|--- |11.3 --- Comment #2 from Andrew Pinski --- (In reply to Tamar Christina from comment #1) > An additional ICE seen on a month old tree is > unsure if this was fixed or just hidden... It is extra checking (that is --enable-checking vs --enable-checking=release): 504 gcc_checking_assert (is_constant ()); #7 0x0189d858 in nunits_for_known_piecewise_op (type=0xf5bc91b0) at /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/tree-vect-generic.c:101 101 return TYPE_VECTOR_SUBPARTS (type).to_constant (); (gdb) p type $1 = (const_tree) 0xf5bc91b0 (gdb) p debug_generic_expr(type) vector([2,2]) float #10 0x018a97a8 in expand_vector_operations_1 (gsi=0xf570, dce_ssa_names=0xf588) at /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/tree-vect-generic.c:2331 (gdb) p code $9 = MULT_EXPR (gdb) p type $10 = (tree) 0xf5bc91b0 (gdb) p debug_generic_expr(type) vector([2,2]) float //E_VNx2SFmode (gdb) p op $12 = smul_optab (gdb) p debug_generic_expr(compute_type) float (gdb) p debug_generic_expr(get_compute_type(code, op, type)) float (gdb) p optab_handler(op, E_VNx2SFmode) $23 = CODE_FOR_nothing (gdb) p op $24 = smul_optab I don't know enough of the SVE backend to understand VNx2SF vs VNx4SF really and why the vectorizer is chosing VNx2SF mode here which does not support half of the instructions (according to the backend).
[Bug sanitizer/103519] Address sanitizer check missing for AVX512 masked load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103519 --- Comment #2 from Hongtao.liu --- get_mem_refs_of_builtin_call doesn't handle target-specific builtins.
[Bug d/103520] [12 regression] ICE: onRangeError
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103520 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fa10faa72d8e9e97b6e564f8b0a7b602538d0da0 commit r12-5704-gfa10faa72d8e9e97b6e564f8b0a7b602538d0da0 Author: Iain Buclaw Date: Wed Dec 1 23:56:28 2021 +0100 d: Disable the D runtime garbage collector after initializing (PR103520) Not all targets that support building libdruntime have a stable garbage collector, so to avoid running into problems where live memory allocated by the D GC is freed, disable all in-flight collections until a time when scanning is more reliably implemented everywhere. PR d/103520 gcc/d/ChangeLog: * d-frontend.h (gc_disable): Declare. * d-lang.cc (d_init_options): Disable the D runtime garbage collector after initializing.
[Bug target/103383] Microblaze bswaphi2 can cause issues with delay slots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103383 Andrew Pinski changed: What|Removed |Added Summary|Microblaze bswaphi2 |Microblaze bswaphi2 can ||cause issues with delay ||slots --- Comment #5 from Andrew Pinski --- Note I have no way to test the patch which I put here. I hope someone who understands Microblaze better and has a reasonable way to test it to take over this bug report. Also the maintainer of Microblaze seems not to be very active either ...
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > I think we should come up with a better plan in general for "flow sensative" > warnings really. Maybe only enable them with -O2 and above. But we keep on > getting more and more of them where it is only defined at runtime if it is > hit. > The other thing is not having it in -W -Wall. Or maybe even adding a way > (outside of -fsantizer=*) to have runtime checks inside the flow where this > happen. Just to note, I was wrong before in talking about this case (and others) because I didn't realize how much code is going to run into these issues. I think Aldy did put it correct when he wrote: "These false positives "by design" arguments are just a cop-out.".
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 103483, which changed state. Bug 103483 Summary: context-sensitive ranges change triggers stringop-overread https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX |---
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 Andrew Pinski changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|NEW --- Comment #8 from Andrew Pinski --- I think we should come up with a better plan in general for "flow sensative" warnings really. Maybe only enable them with -O2 and above. But we keep on getting more and more of them where it is only defined at runtime if it is hit. The other thing is not having it in -W -Wall. Or maybe even adding a way (outside of -fsantizer=*) to have runtime checks inside the flow where this happen.
[Bug analyzer/102471] RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:860c56b5bc356960a4d0445dadc43ceddbe3c7e2 commit r12-5701-g860c56b5bc356960a4d0445dadc43ceddbe3c7e2 Author: David Malcolm Date: Wed Dec 1 14:12:33 2021 -0500 analyzer: fix false leak seen in Juliet 1.3 [PR102471] Juliet 1.3's CWE415_Double_Free__malloc_free_*_67a.c were showing leak false positives in non-LTO builds; fixed thusly. gcc/analyzer/ChangeLog: PR analyzer/102471 * region-model-reachability.cc (reachable_regions::handle_parm): Treat all svalues within a compound parm has reachable, and those wrapped in a cast. gcc/testsuite/ChangeLog: PR analyzer/102471 * gcc.dg/analyzer/leak-3.c: New test. Signed-off-by: David Malcolm
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #12 from Tomas Kalibera --- I've tested with GCC 10.3 with R. R can be built and passes its tests (without the patch, it crashes). Also, I've checked the generated assembly with an awk script looking for a call instruction immediately followed by .seh_endproc. I didn't find any (while there were many without the patch, based on one the attached example was created). Thanks for the fix.
[Bug c++/102881] gcc totally broken when trailing return type combine with decltype lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102881 --- Comment #4 from Uroš Bizjak --- > The master branch has been updated by Uros Bizjak : Oops, wrong PR number...
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 --- Comment #10 from qinzhao at gcc dot gnu.org --- looks like that this is exactly the same issue as exposed in pr102285. and the original fix to pr102285 just hide this inconsistent IR issue. -mno-strict-align exposed this issue again. So. I believe that we need to fix the inconsistent IR issue in order to completely resolve this issue.
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #7 from Steve Kargl --- On Wed, Dec 01, 2021 at 09:42:44PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 > > --- Comment #6 from anlauf at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #5) > > Ah yes. Good catch. Are you going to insert the 2 lines > > lower int the file? If so, I think you can considered > > the patch complete and reviewed. > > Unfortunately this regresses on gfortran.dg/arith_divide_2.f90, > another testcase submitted by Gerhard. We lose the information > on division by zero... > Bummer. Is the regression an ICE or a segfault on execution. The former is unacceptable. The latter is user error and the testcase can be removed.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #26 from Uroš Bizjak --- The testcase now compiles with -O2 -mf16c to: vpxor %xmm2, %xmm2, %xmm2 vpblendw$1, %xmm0, %xmm2, %xmm0 vpblendw$1, %xmm1, %xmm2, %xmm1 vcvtph2ps %xmm1, %xmm1 vcvtph2ps %xmm0, %xmm0 vaddss %xmm1, %xmm0, %xmm0 vinsertps $0xe, %xmm0, %xmm0, %xmm0 vcvtps2ph $4, %xmm0, %xmm0 ret for 64-bit targets and: vpxor %xmm2, %xmm2, %xmm2 vpinsrw $0, 4(%esp), %xmm2, %xmm0 vpinsrw $0, 8(%esp), %xmm2, %xmm1 vcvtph2ps %xmm0, %xmm0 vcvtph2ps %xmm1, %xmm1 vaddss %xmm1, %xmm0, %xmm0 vinsertps $0xe, %xmm0, %xmm0, %xmm0 vcvtps2ph $4, %xmm0, %xmm0 ret for 32-bit targets. Fixed.
[Bug c++/102881] gcc totally broken when trailing return type combine with decltype lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102881 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:7eb961d83b0eda53aeb1cfaacdc367e1952de613 commit r12-5700-g7eb961d83b0eda53aeb1cfaacdc367e1952de613 Author: Uros Bizjak Date: Wed Dec 1 23:01:09 2021 +0100 i386: Improve V8HI and V8HF inserts [PR102811] Introduce vec_set_0 pattern for V8HI and V8HF modes to implement scalar element 0 inserts to from a GP register, SSE register or memory. Also add V8HI and V8HF AVX2 (x,x,x) alternative to PINSR insn pattern, which is split after reload to a sequence of PBROADCASTW and PBLENDW. The V8HF inserts from memory improve from: - vpbroadcastw4(%esp), %xmm1 - vpblendw$16, %xmm1, %xmm0, %xmm0 + vpinsrw $4, 4(%esp), %xmm0, %xmm0 and V8HF inserts from SSE register to element 0 improve from: vpxor %xmm2, %xmm2, %xmm2 - vpbroadcastw%xmm0, %xmm0 vpblendw$1, %xmm0, %xmm2, %xmm0 Based on the above improvements, the register allocator is able to determine the optimal instruction (or instruction sequence) based on the register set of the input value, so there is no need to manually expand V8HI and V8HF inserts to the sequence of VEC_DUPLICATE and VEC_MERGE RTXes. 2021-12-01 Uroš Bizjak gcc/ChangeLog: PR target/102811 * config/i386/sse.md (VI2F): Remove mode iterator. (VI2F_256_512): New mode iterator. (vec_set_0): New insn pattern. (vec_set_0>): Rename from vec_setmode. Use VI2F_256_512 mode iterator instead of VI2F. (*axv512fp16_movsh): Remove. (_pinsr): Add (x,x,x) AVX2 alternative. Do not disable V8HF mode insn on AVX2 targets. (pinsrw -> pbroadcast + pblendw peephole2): New peephole. (pinsrw -> pbroadcast + pblendw splitter): New post-reload splitter. * config/i386/i386.md (extendhfsf): Call gen_vec_setv8hf_0. * config/i386/i386-expand.c (ix86_expand_vector_set) : Use vec_merge path for TARGET_AVX2. gcc/testsuite/ChangeLog: PR target/102881 * gcc.target/i386/pr102811-1.c: New test. * gcc.target/i386/avx512fp16-1c.c (dg-final): Update scan-assembler-times scan strings for ia32 targets. * gcc.target/i386/pr102327-1.c (dg-final): Ditto. * gcc.target/i386/pr102811.c: Rename from ... * gcc.target/i386/avx512vl-vcvtps2ph-pr102811.c: ... this.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #25 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:7eb961d83b0eda53aeb1cfaacdc367e1952de613 commit r12-5700-g7eb961d83b0eda53aeb1cfaacdc367e1952de613 Author: Uros Bizjak Date: Wed Dec 1 23:01:09 2021 +0100 i386: Improve V8HI and V8HF inserts [PR102811] Introduce vec_set_0 pattern for V8HI and V8HF modes to implement scalar element 0 inserts to from a GP register, SSE register or memory. Also add V8HI and V8HF AVX2 (x,x,x) alternative to PINSR insn pattern, which is split after reload to a sequence of PBROADCASTW and PBLENDW. The V8HF inserts from memory improve from: - vpbroadcastw4(%esp), %xmm1 - vpblendw$16, %xmm1, %xmm0, %xmm0 + vpinsrw $4, 4(%esp), %xmm0, %xmm0 and V8HF inserts from SSE register to element 0 improve from: vpxor %xmm2, %xmm2, %xmm2 - vpbroadcastw%xmm0, %xmm0 vpblendw$1, %xmm0, %xmm2, %xmm0 Based on the above improvements, the register allocator is able to determine the optimal instruction (or instruction sequence) based on the register set of the input value, so there is no need to manually expand V8HI and V8HF inserts to the sequence of VEC_DUPLICATE and VEC_MERGE RTXes. 2021-12-01 Uroš Bizjak gcc/ChangeLog: PR target/102811 * config/i386/sse.md (VI2F): Remove mode iterator. (VI2F_256_512): New mode iterator. (vec_set_0): New insn pattern. (vec_set_0>): Rename from vec_setmode. Use VI2F_256_512 mode iterator instead of VI2F. (*axv512fp16_movsh): Remove. (_pinsr): Add (x,x,x) AVX2 alternative. Do not disable V8HF mode insn on AVX2 targets. (pinsrw -> pbroadcast + pblendw peephole2): New peephole. (pinsrw -> pbroadcast + pblendw splitter): New post-reload splitter. * config/i386/i386.md (extendhfsf): Call gen_vec_setv8hf_0. * config/i386/i386-expand.c (ix86_expand_vector_set) : Use vec_merge path for TARGET_AVX2. gcc/testsuite/ChangeLog: PR target/102881 * gcc.target/i386/pr102811-1.c: New test. * gcc.target/i386/avx512fp16-1c.c (dg-final): Update scan-assembler-times scan strings for ia32 targets. * gcc.target/i386/pr102327-1.c (dg-final): Ditto. * gcc.target/i386/pr102811.c: Rename from ... * gcc.target/i386/avx512vl-vcvtps2ph-pr102811.c: ... this.
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #5) > Ah yes. Good catch. Are you going to insert the 2 lines > lower int the file? If so, I think you can considered > the patch complete and reviewed. Unfortunately this regresses on gfortran.dg/arith_divide_2.f90, another testcase submitted by Gerhard. We lose the information on division by zero...
[Bug target/103523] [11/12 Regression] SVE float auto-vect float format expand failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523 --- Comment #1 from Tamar Christina --- An additional ICE seen on a month old tree is during GIMPLE pass: veclower2 zbuf.i: In function 'd': zbuf.i:3:1: internal compiler error: in to_constant, at poly-int.h:504 0xbc9494 poly_int_pod<2u, unsigned long>::to_constant() const /buildAgent/src/gcc/gcc/poly-int.h:504 0x17c16af nunits_for_known_piecewise_op /buildAgent/src/gcc/gcc/tree-vect-generic.c:101 0x17c2377 expand_vector_piecewise /buildAgent/src/gcc/gcc/tree-vect-generic.c:315 0x17c75e5 expand_vector_operation /buildAgent/src/gcc/gcc/tree-vect-generic.c:1254 0x17cde8e expand_vector_operations_1 /buildAgent/src/gcc/gcc/tree-vect-generic.c:2331 0x17ce083 expand_vector_operations /buildAgent/src/gcc/gcc/tree-vect-generic.c:2365 0x17ce25a execute /buildAgent/src/gcc/gcc/tree-vect-generic.c:2451 unsure if this was fixed or just hidden...
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #5 from Steve Kargl --- On Wed, Dec 01, 2021 at 08:26:25PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 > > --- Comment #4 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c > > index 6552eaf3b0c..1b2f5b310a7 100644 > > --- a/gcc/fortran/array.c > > +++ b/gcc/fortran/array.c > > @@ -492,6 +492,9 @@ match_array_element_spec (gfc_array_spec *as) > >if (!gfc_expr_check_typed (*upper, gfc_current_ns, false)) > > return AS_UNKNOWN; > > > > + if ((*upper)->expr_type != EXPR_CONSTANT) > > +gfc_simplify_expr (*upper,0); > > + > >if (((*upper)->expr_type == EXPR_CONSTANT > > && (*upper)->ts.type != BT_INTEGER) || > >((*upper)->expr_type == EXPR_FUNCTION > > There's a second place where this needs to be inserted for > the real upper bound to fix e.g. > > integer, parameter :: z(1:(2.)) = [4, 8] > Ah yes. Good catch. Are you going to insert the 2 lines lower int the file? If so, I think you can considered the patch complete and reviewed.
[Bug target/103523] New: [12 Regression] SVE float auto-vect float format expand failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103523
Bug ID: 103523
Summary: [12 Regression] SVE float auto-vect float format
expand failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*
The following testcase
float *a;
b, c;
d() {
float e;
for (; c; c--, e += b)
a[c] = e;
}
ICEs with -march=armv8-a+sve -mtune=neoverse-v1 -Ofast, the ICE requires SVE to
be enabled but also requires the neoverse-v1 tuning model to trigger.
The ICE is
during RTL pass: expand
zbuf.i: In function 'd':
zbuf.i:3:1: internal compiler error: in format_helper, at real.h:233
3 | d() {
| ^
0xb20be3 format_helper::format_helper(machine_mode const&)
/buildAgent/work/aca863c599d7ab73/gcc/real.h:233
0xb20be3 expand_float(rtx_def*, rtx_def*, int)
/buildAgent/work/aca863c599d7ab73/gcc/optabs.c:5282
0x902f37 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/buildAgent/work/aca863c599d7ab73/gcc/expr.c:9607
0x7f2c4b expand_gimple_stmt_1
/buildAgent/work/aca863c599d7ab73/gcc/cfgexpand.c:3967
0x7f2c4b expand_gimple_stmt
/buildAgent/work/aca863c599d7ab73/gcc/cfgexpand.c:4028
0x7f7903 expand_gimple_basic_block
/buildAgent/work/aca863c599d7ab73/gcc/cfgexpand.c:6069
0x7f9f97 execute
/buildAgent/work/aca863c599d7ab73/gcc/cfgexpand.c:6795
[Bug tree-optimization/103409] [12 Regression] 18% SPEC2017 WRF compile-time regression with -O2 -flto since r12-5228-gb7a23949b0dcc4205fcc2be6b84b91441faa384d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409 --- Comment #13 from hubicka at kam dot mff.cuni.cz --- > I've fixed the threading slowdown. Can someone verify and close this PR if > all > the slowdown has been accounted for? If not, then someone needs to explore > any > slowdown unrelated to the threader. The plots linked from the PR are live, so they should come back to original speed (so far they did not). https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=226.548.8 and https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8
[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103513
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #5 from David Binderman ---
Another test case:
$ more bug778.c
int us_1, func_8_i_8;
void func_8(int s_4)
{
func_8_i_8 = 7;
for (;;)
if (func_8_i_8 * (func_8_i_8 != s_4))
for (;;)
;
}
void func_7_s_4()
{
func_8(us_1 && func_7_s_4);
}
$
[Bug tree-optimization/103522] New: New test case gcc.dg/ubsan/pr103456.c fails in r12-5649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103522 Bug ID: 103522 Summary: New test case gcc.dg/ubsan/pr103456.c fails in r12-5649 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:da9386f9a70ac494939650c0e0a0e4168a6f76d8, r12-5649 make -k check-gcc RUNTESTFLAGS="ubsan.exp=gcc.dg/ubsan/pr103456.c" # of expected passes15 # of unresolved testcases 1 This is on powerpc64 LE. commit da9386f9a70ac494939650c0e0a0e4168a6f76d8 (HEAD, refs/bisect/bad) Author: Siddhesh Poyarekar Date: Wed Dec 1 12:58:12 2021 +0530 tree-optimization/103456 - Record only successes from object_sizes_set
[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103505 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c > index 6552eaf3b0c..1b2f5b310a7 100644 > --- a/gcc/fortran/array.c > +++ b/gcc/fortran/array.c > @@ -492,6 +492,9 @@ match_array_element_spec (gfc_array_spec *as) >if (!gfc_expr_check_typed (*upper, gfc_current_ns, false)) > return AS_UNKNOWN; > > + if ((*upper)->expr_type != EXPR_CONSTANT) > +gfc_simplify_expr (*upper,0); > + >if (((*upper)->expr_type == EXPR_CONSTANT > && (*upper)->ts.type != BT_INTEGER) || >((*upper)->expr_type == EXPR_FUNCTION There's a second place where this needs to be inserted for the real upper bound to fix e.g. integer, parameter :: z(1:(2.)) = [4, 8]
[Bug d/103520] [12 regression] ICE: onRangeError
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103520 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |12.0 Keywords||build, ice-on-valid-code
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #11 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:de3e5aae6c4b540e808c822c1e878b0a3304d09c
commit r12-5699-gde3e5aae6c4b540e808c822c1e878b0a3304d09c
Author: Roger Sayle
Date: Wed Dec 1 19:58:40 2021 +
Final value replacement improvements for until-wrap loops.
This middle-end patch is inspired by the Richard Beiner's until-wrap
loop example in PR tree-optimization/101145.
unsigned foo(unsigned val, unsigned start)
{
unsigned cnt = 0;
for (unsigned i = start; i > val; ++i)
cnt++;
return cnt;
}
For this loop, the tree optimizers currently generate:
unsigned int foo (unsigned int val, unsigned int start)
{
unsigned int cnt;
unsigned int _1;
unsigned int _5;
[local count: 118111600]:
if (start_3(D) > val_4(D))
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 105119324]:
_1 = start_3(D) + 1;
_5 = -start_3(D);
cnt_2 = _1 > val_4(D) ? _5 : 1;
[local count: 118111600]:
# cnt_11 = PHI
return cnt_11;
}
or perhaps slightly easier to read:
if (start > val) {
cnt = (start+1) > val ? -start : 1;
} else cnt = 0;
In this snippet, if we know start > val, then (start+1) > val
unless start+1 overflows, i.e. (start+1) == 0 and start == ~0.
We can use this (loop header) context to simplify the ternary
expression to "(start != -1) ? -start : 1", which with a little
help from match.pd can be folded to -start. Hence the optimal
final value replacement should be:
cnt = (start > val) ? -start : 0;
Or as now generated by this patch:
unsigned int foo (unsigned int val, unsigned int start)
{
unsigned int cnt;
[local count: 118111600]:
if (start_3(D) > val_4(D))
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 105119324]:
cnt_2 = -start_3(D);
[local count: 118111600]:
# cnt_11 = PHI
return cnt_11;
}
We can also improve until-wrap loops that don't have a (suitable) loop
header, as determined by simplify_using_initial_conditions.
unsigned bar(unsigned val, unsigned start)
{
unsigned cnt = 0;
unsigned i = start;
do {
cnt++;
i++;
} while (i > val);
return cnt;
}
which is currently optimized to:
unsigned int foo (unsigned int val, unsigned int start)
{
unsigned int cnt;
unsigned int _9;
unsigned int _10;
[local count: 118111600]:
_9 = start_4(D) + 1;
_10 = -start_4(D);
cnt_3 = val_7(D) < _9 ? _10 : 1;
return cnt_3;
}
Here we have "val < (start+1) ? -start : 1", which again with the
help of match.pd can be slightly simplified to "val <= start ? -start : 1"
when dealing with unsigned types, because at the complicating value where
start == ~0, we fortunately have -start == 1, hence it doesn't matter
whether the second or third operand of the ternary operator is returned.
To summarize, this patch (in addition to tweaking may_be_zero in
number_of_iterations_until_wrap) adds three new constant folding
transforms to match.pd.
X != C1 ? -X : C2 simplifies to -X when -C1 == C2.
which is the generalized form of the simplification above.
X != C1 ? ~X : C2 simplifies to ~X when ~C1 == C2.
which is the BIT_NOT_EXPR analog of the NEGATE_EXPR case.
and the "until-wrap final value replacement without context":
(X + 1) > Y ? -X : 1 simplifies to X >= Y ? -X : 1 when
X is unsigned, as when X + 1 overflows, X is -1, so -X == 1.
2021-12-01 Roger Sayle
Richard Biener
gcc/ChangeLog
* tree-ssa-loop-niter.c (number_of_iterations_until_wrap):
Check if simplify_using_initial_conditions allows us to
simplify the expression for may_be_zero.
* match.pd (X != C ? -X : -C -> -X): New transform.
(X != C ? ~X : ~C -> ~X): Likewise.
((X+1) > Y ? -X : 1 -> X >= Y ? -X : 1): Likewise.
gcc/testsuite/ChangeLog
* gcc.dg/fold-condneg-1.c: New test case.
* gcc.dg/fold-condneg-2.c: New test case.
* gcc.dg/fold-condnot-1.c: New test case.
* gcc.dg/pr101145-1.c: New test case.
* gcc.dg/pr101145-2.c: New test case.
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 --- Comment #9 from qinzhao at gcc dot gnu.org --- disable tree-ccp by adding -fno-tree-ccp cures the ICE.
[Bug middle-end/103127] ICE in fold_convert_loc with __vector_quad and -ftrivial-auto-var-init=pattern on powerpc64*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Peter Bergner --- Fixed on trunk.
[Bug middle-end/103127] ICE in fold_convert_loc with __vector_quad and -ftrivial-auto-var-init=pattern on powerpc64*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127 --- Comment #12 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:5b1ef8b9db964ec2375df29a73d2b1651afe7ea9 commit r12-5698-g5b1ef8b9db964ec2375df29a73d2b1651afe7ea9 Author: Peter Bergner Date: Wed Dec 1 13:17:52 2021 -0600 middle-end: Skip initialization of opaque type variables [PR103127] For -ftrivial-auto-var-init=*, skip initializing the variable if it is an opaque type, because CONST0_RTX(mode) is not defined for opaque modes. 2021-12-01 Peter Bergner gcc/ PR middle-end/103127 * gimplify.c (is_var_need_auto_init): Handle opaque types. gcc/testsuite/ PR middle-end/103127 * gcc.target/powerpc/pr103127.c: New test.
[Bug analyzer/103521] New: [12 regression] gcc.dg/analyzer/pr93032-mztools.c broken after r12-5585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103521 Bug ID: 103521 Summary: [12 regression] gcc.dg/analyzer/pr93032-mztools.c broken after r12-5585 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:132902177138c09803d639e12b1daebf2b9edddc, r12-5585 make -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/pr93032-mztools.c" FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpZip (test for warnings, line 328) FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpOut (test for warnings, line 328) FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpOutCD (test for warnings, line 328) FAIL: gcc.dg/analyzer/pr93032-mztools.c (test for excess errors) # of unexpected failures4 commit 132902177138c09803d639e12b1daebf2b9edddc (HEAD, refs/bisect/bad) Author: David Malcolm Date: Mon Nov 29 11:47:47 2021 -0500 analyzer: further false leak fixes due to overzealous state merging [PR103217] spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c -fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o pr93032-mztools.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c: In function 'unzRepair': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:174:15: warning: terminating analysis for this program point: callstring: [] before (SN: 34 stmt: 0): free (data_386);EN: 164-166, EN: 391, EN: 587-588, EN: 753, EN: 949 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:157:15: warning: terminating analysis for this program point: callstring: [] before (SN: 25 stmt: 0): dataSize_383 = (int) cpsize_361;EN: 96-97, EN: 357, EN: 519-520, EN: 719, EN: 881-882 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: callstring: [] before (SN: 56 stmt: 0): entriesZip_459 = entries_306;EN: 1107-1114 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning: terminating analysis for this program point: callstring: [] before (SN: 68 stmt: 0): _295 = fread (, 1, 8192, fpOutCD_492);EN: 1268-1272, EN: 1284, EN: 1291, EN: 1298 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning: terminating analysis for this program point: callstring: [] before (SN: 68 stmt: 0): _295 = fread (, 1, 8192, fpOutCD_492);EN: 1268-1272, EN: 1284, EN: 1291, EN: 1298 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c: At top level: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:322:25: warning: analysis bailed out early (401 'after-snode' enodes; 1440 enodes) [-Wanalyzer-too-complex] FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpZip (test for warnings, line 328) FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpOut (test for warnings, line 328) FAIL: gcc.dg/analyzer/pr93032-mztools.c leak of fpOutCD (test for warnings, line 328) Executing on host: /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled349827.cc -fdiagnostics-plain-output -S -o exceptions_enabled349827.s(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled349827.cc -fdiagnostics-plain-output -S -o exceptions_enabled349827.s FAIL: gcc.dg/analyzer/pr93032-mztools.c (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:174:15: warning: terminating analysis for this program point: callstring: [] before (SN: 34 stmt: 0): free (data_386);EN: 164-166, EN: 391, EN: 587-588, EN: 753, EN: 949 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:157:15: warning: terminating analysis for this program point: callstring: [] before (SN: 25 stmt: 0): dataSize_383 = (int) cpsize_361;EN: 96-97, EN: 357, EN: 519-520, EN: 719, EN: 881-882 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:261:11: warning: terminating analysis for this program point: callstring: [] before (SN: 56 stmt: 0): entriesZip_459 = entries_306;EN: 1107-1114 [-Wanalyzer-too-complex] /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/pr93032-mztools.c:299:31: warning: terminating analysis for this program point: callstring: [] before (SN: 68 stmt:
[Bug c++/103319] [coroutines] ICE in is_this_parameter, at cp/semantics.c:10672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103319 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.3 --- Comment #3 from Jason Merrill --- (In reply to Avi Kivity from comment #2) > A gentle ping, can we backport this? Done.
[Bug c/103310] null comparison with a weak symbol eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103310 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:53caa4723d8de73fe21e63ba264082f3071b2887 commit r12-5696-g53caa4723d8de73fe21e63ba264082f3071b2887 Author: Jason Merrill Date: Wed Nov 24 05:45:02 2021 -0500 c++: constexpr, fold, weak redecl, fp/0 [PR103310] For PR61825, honza changed tree_single_nonzero_warnv_p to prevent a later declaration from marking a function as weak after we've determined that it wasn't weak before. But we shouldn't do that for speculative folding; we should only do it when we actually need a constant value. In C++, such a context is called "manifestly constant-evaluated". In fold, this seems to correspond to the folding_initializer flag, since in C this situation only occurs in static initializers. This change makes nonzero-1.c well-formed; I've added a nonzero-1a.c to verify that we delete the null check eventually if there is no weak redeclaration. The varasm.c change is so that if we do get the weak redeclaration error, we get it at the position of the weak declaration rather than the previous declaration. Using the FOLD_INIT paths also affects floating point arithmetic: notably, this makes floating point division by zero in a manifestly constant-evaluated context constant, as in a C static initializer. I've had some success convincing CWG that this is the right direction; C++ should follow C's floating point semantics more than we have been doing, and Joseph says that the C policy is that Annex F overrides other parts of the standard that say that some operations are undefined. But since we're in stage 3, I'm only making this change with the new flag -fconstexpr-fp-except. It may turn on by default in a future release. I think this distinction is only relevant for binary operations; arithmetic for the floating point case, comparison for possibly non-zero addresses. PR c++/103310 gcc/ChangeLog: * fold-const.c (maybe_nonzero_address): Use get_create or get depending on folding_initializer. (fold_binary_initializer_loc): New. * fold-const.h (fold_binary_initializer_loc): Declare. * varasm.c (mark_weak): Don't use the decl location. * doc/invoke.texi: Document -fconstexpr-fp-except. gcc/c-family/ChangeLog: * c.opt: Add -fconstexpr-fp-except. gcc/cp/ChangeLog: * constexpr.c (cxx_eval_binary_expression): Use fold_binary_initializer_loc if manifestly cxeval. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-fp-except1.C: New test. * g++.dg/cpp1z/constexpr-if36.C: New test. * gcc.dg/tree-ssa/nonzero-1.c: Now well-formed. * gcc.dg/tree-ssa/nonzero-1a.c: New test.
[Bug tree-optimization/103491] nextafter does not raise "overflow" and "inexact" floating-point exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491 --- Comment #4 from Pavel M --- To: jos...@codesourcery.com Re: This testcase is incorrect. Indeed. The F.10.8.3 was misunderstood.
[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347 --- Comment #13 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:d683a1b3e89007211a7c800bb61647d8ac42cb6b commit r12-5695-gd683a1b3e89007211a7c800bb61647d8ac42cb6b Author: Bill Schmidt Date: Wed Dec 1 09:20:15 2021 -0600 rs6000: Mirror fix for PR102347 in new builtins support Recently Kewen fixed a problem in the old builtins support where rs6000_builtin_decl prematurely indicated that a target builtin is unavailable. This also needs to be done for the new builtins support, but in this case we have to ensure the error message is still produced from the overload support in rs6000-c.c. Unfortunately, this is less straightforward than it could be, because header file includes need to be adjusted to make this happen. Someday we'll consolidate all the builtin code in one file and this won't have to be so ugly. 2021-12-01 Bill Schmidt gcc/ PR target/102347 * config/rs6000/rs6000-c.c (rs6000-builtins.h): Stop including. (rs6000-internal.h): Include. (altivec_resolve_new_overloaded_builtin): Move call to rs6000_invalid_new_builtin here from rs6000_new_builtin_decl. * config/rs6000/rs6000-call.c (rs6000-builtins.h): Stop including. (rs6000_invalid_new_builtin): Remove static qualifier. (rs6000_new_builtin_decl): Remove test for supported builtin. * config/rs6000/rs6000-internal.h (rs6000-builtins.h): Include. (rs6000_invalid_new_builtin): Declare. * config/rs6000/rs6000.c (rs6000-builtins.h): Don't include.
[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103501 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > I haven't checked the unordered containers yet to see if they have the same > issue. This still needs to be done.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Eric Gallager changed: What|Removed |Added CC||allan.chandler at oakton dot com.a ||u, damien at iwi dot me, ||dietmar.schindler@manroland ||goss.com, ||dmalcolm at gcc dot gnu.org, ||marco.lattuada at polimi dot it, ||max at maxbruckner dot de, ||miyuki at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||rainarchitect at gmail dot com, ||robert.simpson.lists@gmail. ||com, ||ruslan_baratov at yahoo dot com, ||scottbaldwin at gmail dot com, ||TrevorJamesHickey at gmail dot com ||, ulidtko at gmail dot com, ||_hamlet at libero dot it --- Comment #43 from Eric Gallager --- Came up again about the new -Wbidi-chars option here: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585777.html (I'm also taking this time to re-add some CCs that got lost without being listed as being removed in the bug history, presumably due to server migration)
[Bug analyzer/102471] RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from David Malcolm --- I've got a primitive workflow of running the Juliet 1.3 testsuite, and a script for testing results here: https://github.com/davidmalcolm/juliet-harness Currently I've only run it on the: C/testcases/CWE415_Double_Free/s01 sudirectory, with: # of passes 130 # of failures 103 I'm looking through the failures.
[Bug ipa/103267] Wrong code with ipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103267 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Jambor --- Fixed (with the caveat explained in comment #10) on master and all opened release branches, thus closing.
[Bug ipa/103267] Wrong code with ipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103267 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:7dd5b92bbe0944dc27e6175b0df72ed0a7188016 commit r9-9852-g7dd5b92bbe0944dc27e6175b0df72ed0a7188016 Author: Martin Jambor Date: Wed Dec 1 18:29:50 2021 +0100 ipa-sra: Check also ECF_LOOPING_CONST_OR_PURE when evaluating calls in PR 103267 Honza found out that IPA-SRA does not look at ECF_LOOPING_CONST_OR_PURE when evaluating if a call can have side effects. Fixed with this patch. The testcase infinitely loops in a const function, so it would not make a good addition to the testsuite. This patch is a manual backport of commit e5440bc08e07fd491dcccd47e1b86a5985ee117c to the old "early" IPA-SRA. gcc/ChangeLog: 2021-12-01 Martin Jambor PR ipa/103267 * tree-sra.c (scan_function): Also check ECF_LOOPING_CONST_OR_PURE flag.
[Bug c++/94490] Ternary expression with 3 consts is “not” a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94490 --- Comment #5 from Marek Polacek --- Patch finally posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585932.html
[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 --- Comment #8 from qinzhao at gcc dot gnu.org --- the minimum option to repeat this failure is "-O1 -mno-strict-align". The option "-mno-strict-align" is the one that make the difference. For the following call to .DEFERRED_INIT: MEM[(int[0:D.1492] *)] = .DEFERRED_INIT (16, 1, 1); the LHS is MEM[(int[0:D.1492] *)]. When -mno-strict-align is NOT present, "mem_ref_refers_to_non_mem_p (lhs_base)" return FALSE, lHS is considered as MEM, and the call is expanded through "memset" path. No issue. when -mno-strict-align is present, "mem_ref_refers_to_non_mem_p (lhs_base)" return TRUE, as a result, LHS is considered to be put into a register, and then the call is expanded through "expand_assignment" path. The major issue during expanding through "expand_assignment" path is: although the LHS "MEM[(int[0:D.1492] *)]" is decided to be put into register with TI mode, however, the TREE_TYPE of LHS is still a VLA type, such inconsistency in IR cause the final ICE. with the option -mno-strict-align, the IR of lhs_base is: (gdb) call debug_tree(lhs_base) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type 0x707465e8 precision:32 min max pointer_to_this > sizes-gimplified type_1 BLK size used unsigned ignored TI t.c:8:7 size unit-size align:128 warn_if_not_align:0 context > unit-size used unsigned ignored DI t.c:8:7 size unit-size align:64 warn_if_not_align:0 context > align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality domain sizes-gimplified DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality precision:64 min max > pointer_to_this > nothrow arg:0 unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7082c2a0> arg:0 used ignored TI t.c:8:7 size unit-size align:64 warn_if_not_align:0 context (reg:TI 72 [ fb.3 ])>> arg:1 constant 0> t.c:8:7 start: t.c:8:7 finish: t.c:8:8> >From the above IR, we can see, 1. the base address of this mem_ref is arg:0 used ignored TI t.c:8:7 size unit-size align:64 warn_if_not_align:0 context (reg:TI 72 [ fb.3 ])>> which is in register of TI mode; 2. However, the TREE_TYPE of this mem_ref is still a VLA type. when call "build_zero_cst (var_type)", the var_type is a VLA type, therefore the ICE. My suspicion is, -mno-strict-align applied some kind of optimization that turn the var_decl from: arg:0 used ignored BLK t.c:8:7 size unit-size align:128 warn_if_not_align:0 context (mem/c:BLK (plus:DI (reg/f:DI 67 virtual-stack-vars) (const_int -16 [0xfff0])) [0 fb.3+0 S16 A128])>> to: arg:0 used ignored TI t.c:8:7 size unit-size align:64 warn_if_not_align:0 context (reg:TI 72 [ fb.3 ])>> However, the TREE_TYPE of MEM[(int[0:D.1492] *)] is not updated accordingly.
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #7 from Jonathan Wakely ---
I have a patch:
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -54,6 +54,11 @@ namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
+#pragma GCC diagnostic ignored "-Wstringop-overread"
+#pragma GCC diagnostic ignored "-Warray-bounds"
+
/**
* @brief Mapping from character type to associated types.
*
@@ -990,6 +995,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
} // namespace __detail
#endif // C++20
+#pragma GCC diagnostic push
+
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jwakely.gcc at gmail dot com --- Comment #6 from Aldy Hernandez --- (In reply to Martin Sebor from comment #4) > I don't think this can be "fixed." Most middle end warnings work a single > statement at a time and depend on optimization like constant propagation and > dead code elimination to do their job. If one optimization exposes an > invalid statement that would otherwise be eliminated by another optimization > that doesn't take place, the warnings trigger. That's all by design and > there's no way change that. In the test case in comment #0 where the > precondition is that d be less than a, making it explicit (e.g., either as > Andrew suggests in comment #1 or by adding an equivalen assert statement) > seems like the best and only solution. Oh, it totally could be fixed. Whether you want to or not, is a separate issue. These false positives "by design" arguments are just a cop-out. As Jonathan said, if the warning code can't handle the IL as presented, it should give up, not assume code is wrong by default. It seems we do very bad with a lot of these warnings at -O1. We should just disable them at low optimization levels if we can't/won't take measures to reduce the false positive rate here.
[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912 Aldy Hernandez changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #6 from Aldy Hernandez --- (In reply to rguent...@suse.de from comment #5) > On Tue, 30 Nov 2021, eggert at cs dot ucla.edu wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912 > > > > --- Comment #4 from eggert at cs dot ucla.edu --- > > (In reply to Aldy Hernandez from comment #3) > > > > && !(leapcnt == 0 > > > >|| (prevcorr < corr > > > >? corr == prevcorr + 1 > > > >: (corr == prevcorr > > > > || corr == prevcorr - 1) > > > > > > > > > > I guess the question is whether language rules allow us to read prevcorr > > > when leapcnt== 0? > > > > The C language rules do not allow that. When leapcnt is zero, behavior must > > be > > as if the prevcorr expression is not evaluated. > > > > Although the compiler can generate machine code that evaluates prevcorr at > > the > > machine level (so long as the observable behavior is the same, which is the > > case as prevcorr is not volatile and no untoward behavior can result from > > evaluating the prevcorr expression), it's incorrect if the compiler warns > > the > > programmer that prevcorr is used uninitialized. > > Correct. I think we have quite some duplicates around this issue > of making short-circuiting conditionals not short-circuiting (we do > that even early during GENERIC folding). "Proving" that all participating > sub-expressions are fully initialized is impossible so the only > reasonable way to "fix" the issue (the uninit warnings) might be > to mark the now unconditionally evaluated sub-expressions with > -Wno-uninitialized (aka no-warning or suppress uninit warnings). If this isn't something we are going to fix then by all means, mark them all as -Wno-uninitialized. I'm for whatever reduces the false positive rates in this area :).
[Bug tree-optimization/103409] [12 Regression] 18% SPEC2017 WRF compile-time regression with -O2 -flto since r12-5228-gb7a23949b0dcc4205fcc2be6b84b91441faa384d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409 --- Comment #12 from Aldy Hernandez --- I've fixed the threading slowdown. Can someone verify and close this PR if all the slowdown has been accounted for? If not, then someone needs to explore any slowdown unrelated to the threader.
[Bug tree-optimization/103409] [12 Regression] 18% SPEC2017 WRF compile-time regression with -O2 -flto since r12-5228-gb7a23949b0dcc4205fcc2be6b84b91441faa384d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409 --- Comment #11 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:54ebec35abec09a24b47b997172622ca0d8e2318 commit r12-5694-g54ebec35abec09a24b47b997172622ca0d8e2318 Author: Aldy Hernandez Date: Mon Nov 29 14:49:59 2021 +0100 path solver: Use only one ssa_global_cache. We're using a temporary range cache while computing ranges for PHIs to make sure the real cache doesn't get set until all PHIs are computed. With the ltrans beast in LTO mode this causes undue overhead. Since we already have a bitmap to indicate whether there's a cache entry, we can avoid the extra cache object by clearing it while PHIs are being calculated. gcc/ChangeLog: PR tree-optimization/103409 * gimple-range-path.cc (path_range_query::compute_ranges_in_phis): Do all the work with just one ssa_global_cache. * gimple-range-path.h: Remove m_tmp_phi_cache.
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #6 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > Created attachment 51908 [details] > untested patch > > Like this. It fixes the problem at least for -O2. Richi responded that the current BB copier won't handle this: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585884.html
[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090 --- Comment #6 from Jeffrey A. Law --- I never explored the idea, but Bodik has a discussion of recording infeasible paths in the CFG which would seem to address this issue. He was using the concept in the context of coverage analysis -- the idea being if you were supposed to be providing 100% coverage, then you have to know if there are paths that simply can't be executed at runtime that were left in the CFG. Anyway... If we find a thread, but fail to optimize it because of the cost -- we record data in the CFG on the path infeasibility. The uninit pass (or any pass for that matter) could then query that data and realize the path isn't feasible and suppress the warning in that case. My concern with Bodik's approach is the marking and keeping those markings up-to-date through the pipeline. So that's one approach. The other is to introduce the solver into the predicate analysis pass which starts to touch on other ideas I've had. Namely that thread discovery and predicate analysis are closely related. ie, we could be using predicate analysis to discover more threading opportunities and we could be using the path solver to prune out infeasible paths for the uninit (and other) passes by integrating path solving into predicate analysis. What you've done is the first step in this direction.
[Bug middle-end/103127] ICE in fold_convert_loc with __vector_quad and -ftrivial-auto-var-init=pattern on powerpc64*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127 --- Comment #11 from qinzhao at gcc dot gnu.org --- Please see the details of the discussion of the patch for this bug: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg275509.html as a summary, we decide to exclude OPAQUE_TYPE from auto-init at this time. so the fix will be in the routine “is_var_need_auto_init” in gimplify.c to exclude OPAQUE_TYPE from auto-init.
[Bug analyzer/102471] RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471
--- Comment #2 from David Malcolm ---
There's also
https://www.nist.gov/itl/ssd/software-quality-group/other-assurance-tool-test-collections
Currently the only non-Java collection on the list is:
https://sir.csc.ncsu.edu/portal/index.php
However that repository has:
https://sir.csc.ncsu.edu/portal/sir-license.php
which seems to be a non-Open Source licence ("solely for non-commercial,
educational, evaluation and/or personal use").
[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090 --- Comment #5 from Aldy Hernandez --- [from the POC patch] It seems that every missed thread (due to inability of the threader, or due to cost restraints) is a potential false positive for the uninit code. Perhaps what we need is a way to identify threading opportunities without doing the actual threading. The attached is a proof-of-concept that does just that. Basically a lof of these PRs look like: x_5 = PHI ... ... if (cond_8) use(x_5); This looks like a path from the definition of x_5 to the cond_8 check. If the incoming path through BB10 can be determined to elide the use of x_5, we could disregard this as a false positive. This patch solves PR82090, but it would need to be properly incorporated into the uninit pass. For instance, I'm finding paths from USE back to DEF, but the uninit pass is in a much better position to tell us what the starting point of the path is. It's likely to be further up the chain through a maze of feeding PHIs. This is just meant as a stop gap to help in reducing the false positive rate, nothing fancy. Maybe the work by Martin Liska and Richi on loop unswitching would be a better solution. Anywhoo... Maybe someone with knowledge of the uninit pass could explore this. Just a thought.
[Bug tree-optimization/82090] Bogus warning: ‘magic_p’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090 --- Comment #4 from Aldy Hernandez --- Created attachment 51913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51913=edit proof of concept to reduce uninit warnings with the path solver
[Bug libstdc++/96074] Associative containers never propagate allocator on copy assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED|RESOLVED
--- Comment #2 from Jonathan Wakely ---
Your test allocator has a bug. You do not override the is_always_equal trait
from the base class, which means you inherit std::allocator::is_always_equal
which is defined to be std::true_type. So the associative containers elide the
propagation:
if (_Alloc_traits::_S_propagate_on_copy_assign())
{
auto& __this_alloc = this->_M_get_Node_allocator();
auto& __that_alloc = __x._M_get_Node_allocator();
if (!_Alloc_traits::_S_always_equal()
&& __this_alloc != __that_alloc)
{
// Replacement allocator cannot free existing storage, we
need
// to erase nodes first.
clear();
std::__alloc_on_copy(__this_alloc, __that_alloc);
}
}
If I add this to the primary template and the partial specialization then all
tests pass (including the commented-out one for std::stringbuf):
using is_always_equal= std::false_type;
You have been bitten by LWG 3170: https://cplusplus.github.io/LWG/issue3170
std::allocator::is_always_equal is deprecated for precisely this reason
(it's a very annoying trap) but it's still there in C++20, so you need to
override it.
Closing, as the libstdc++ containers are already correct.
[Bug libstdc++/96074] Associative containers never propagate allocator on copy assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96074
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Keywords||wrong-code
--- Comment #1 from Jonathan Wakely ---
Off topic, in your test you have:
// needed for gcc
template
struct rebind { using other = allocator; };
Isn't that needed always? allocator_traits can only provide a default rebind
for an allocator "of the form Alloc, where Args is zero or more type
arguments". Your non-type template arguments prevent that from working.
[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103501 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:056551414a328b427c4bf4955b9a3832f344685c commit r12-5693-g056551414a328b427c4bf4955b9a3832f344685c Author: Jonathan Wakely Date: Tue Nov 30 23:32:50 2021 + libstdc++: Clear RB tree after moving elements [PR103501] If the allocator-extended move constructor move-constructs each element into the new container, the contents of the old container are left in moved-from states. We cannot know if those states preserve the container's ordering and uniqueness guarantees, so just erase all moved-from elements. libstdc++-v3/ChangeLog: PR libstdc++/103501 * include/bits/stl_tree.h (_Rb_tree(_Rb_tree&&, false_type)): Clear container if elements have been moved-from. * testsuite/23_containers/map/allocator/move_cons.cc: Expect moved-from container to be empty. * testsuite/23_containers/multimap/allocator/move_cons.cc: Likewise. * testsuite/23_containers/multiset/allocator/103501.cc: New test. * testsuite/23_containers/set/allocator/103501.cc: New test.
[Bug d/103520] New: [12 regression] ICE: onRangeError
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103520 Bug ID: 103520 Summary: [12 regression] ICE: onRangeError Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: sch...@linux-m68k.org Target Milestone: --- Host: aarch64-*-* Target: aarch64-*-* make[3]: Entering directory '/opt/gcc/gcc-20211201/Build/aarch64-suse-linux/libphobos/libdruntime' /bin/sh ../libtool --tag=D --mode=compile /opt/gcc/gcc-20211201/Build/./gcc/gdc -B/opt/gcc/gcc-20211201/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include -prefer-pic -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc -I ../../../../libphobos/libdruntime -I . -c -o core/internal/gc/bits.lo ../../../../libphobos/libdruntime/core/internal/gc/bits.d libtool: compile: /opt/gcc/gcc-20211201/Build/./gcc/gdc -B/opt/gcc/gcc-20211201/Build/./gcc/ -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem /usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc -I ../../../../libphobos/libdruntime -I . -c ../../../../libphobos/libdruntime/core/internal/gc/bits.d -fPIC -fversion=Shared -o core/internal/gc/.libs/bits.o gcc.deh(515): unwind error d21: internal compiler error: Aborted 0xfbf543 crash_signal ../../gcc/toplev.c:322 0xab44cc48 __pthread_kill_implementation /usr/src/debug/glibc-2.34-3.1.aarch64/nptl/pthread_kill.c:44 0xab40683f __GI_raise ../sysdeps/posix/raise.c:26 0xab3f2df7 __GI_abort /usr/src/debug/glibc-2.34-3.1.aarch64/stdlib/abort.c:79 0x1e26a43 _D3gcc3deh9terminateFNiAyakZv ../../../../libphobos/libdruntime/gcc/deh.d:433 0x1e2b36f onRangeError ../../../../libphobos/libdruntime/core/exception.d:496 0x80a98b Array::push(Dsymbol*) /opt/gcc/gcc-20211201/gcc/d/dmd/root/array.d:120 0x87cf67 _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk9parseEnumMFZCQCo5denum15EnumDeclaration /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:3291 0x870adf _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:537 0x87156f _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk10parseBlockMFPCQCq7dsymbol7DsymbolPSQDlQDk__T16PrefixAttributesTQDsZQxZPSQEw4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:1338 0x8706bf _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:1203 0x8704eb _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:1211 0x8704eb _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:1211 0x8704eb _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:1211 0x8704eb _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:1211 0x87024f _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:889 0x87024f _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:889 0x87024f _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:889 0x87109b _D3dmd5parse__T6ParserTSQw10astcodegen10ASTCodegenZQBk13parseDeclDefsMFiPCQCu7dsymbol7DsymbolPSQDpQDo__T16PrefixAttributesTQDwZQxZPSQFa4root5array__T5ArrayTQDfZQl /opt/gcc/gcc-20211201/gcc/d/dmd/parse.d:967 0x8704b7
[Bug fortran/103507] ICE in resolve_block_construct, at fortran/resolve.c:10787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103507
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
This patch prevents the ICE, but is not as elegant as I would like.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index f074a0ab3a1..08f657407da 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -17553,6 +17553,14 @@ gfc_resolve (gfc_namespace *ns)
code_stack *old_cs_base;
struct gfc_omp_saved_state old_omp_state;
+ if (!ns)
+{
+ int ecnt;
+ gfc_get_errors (NULL, );
+ if (ecnt > 0)
+ gfc_fatal_error ("Namespace corruption due to previous errors");
+}
+
if (ns->resolved)
return;
The problem seems to be with one of more namespaces being
incomplete and/or overlapping.
[Bug sanitizer/103519] Address sanitizer check missing for AVX512 masked load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103519 David Long changed: What|Removed |Added CC||dlong at cadence dot com --- Comment #1 from David Long --- (In case the godbolt link happens to disappear at some point, compilation options are -mavx512f -mavx512vl -mfma -mbmi2 -O -fsanitize=address)
[Bug sanitizer/103519] New: Address sanitizer check missing for AVX512 masked load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103519
Bug ID: 103519
Summary: Address sanitizer check missing for AVX512 masked load
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dlong at cadence dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Example with generated assembly available here: https://godbolt.org/z/WTo5sGThb
In this:
#include
__m512d v;
void
access(float const *addr)
{
__m512d val;
__m256 val1;
__mmask8 const k3 = 0x3f;
val1=_mm256_maskz_loadu_ps(k3, addr);
val=_mm512_cvtps_pd(val1);
_mm512_storeu_pd((double *), val);
}
when compiled with AVX512 instructions and -fsanitize=address, no address check
is generated for the maskz_load.
(FWIW, if the mask is folded into the conversion using maskz_cvtps_pd instead
then a check is generated. However it's a check for a full 32-byte access even
though the CPU will only actually access 24-bytes due to the mask.)
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 103517, which changed state. Bug 103517 Summary: [12 Regression] ICE in as_a, at is-a.h:242 with -O2 -march=skylake-avx512 since r12-5612-g10833849b55401a5 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103517 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/103517] [12 Regression] ICE in as_a, at is-a.h:242 with -O2 -march=skylake-avx512 since r12-5612-g10833849b55401a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103517 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/103517] [12 Regression] ICE in as_a, at is-a.h:242 with -O2 -march=skylake-avx512 since r12-5612-g10833849b55401a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103517 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:1e625a44f6f3001cea31e0f7c563943ecba92b68 commit r12-5689-g1e625a44f6f3001cea31e0f7c563943ecba92b68 Author: Richard Sandiford Date: Wed Dec 1 14:36:24 2021 + vect: Tighten check for SLP memory groups [PR103517] When checking for compatible stmts, vect_build_slp_tree_1 did: && !(STMT_VINFO_GROUPED_ACCESS (stmt_info) && (first_stmt_code == ARRAY_REF || first_stmt_code == BIT_FIELD_REF || first_stmt_code == INDIRECT_REF || first_stmt_code == COMPONENT_REF || first_stmt_code == MEM_REF))) That is, it allowed any rhs_code as long as the first_stmt_code looked valid. This had the effect of allowing IFN_MASK_LOAD to be paired with an earlier non-call code (but didn't allow the reverse). This patch makes the check symmetrical. gcc/ PR tree-optimization/103517 * tree-vect-slp.c (vect_build_slp_tree_1): When allowing two different component references, check the codes of both them, rather than just the first. gcc/testsuite/ PR tree-optimization/103517 * gcc.dg/vect/pr103517.c: New test.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #15 from Andrew Macleod --- Stack frame depth issued should be completely resolved in GCC12 now by patches for PR 103231 and a follow up for PR 103464.
[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103464 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #18 from Andrew Macleod --- fixed.
[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103464 --- Comment #17 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:cb137e85720654e41db370d952df226654e576a6 commit r12-5688-gcb137e85720654e41db370d952df226654e576a6 Author: Andrew MacLeod Date: Mon Nov 29 12:00:26 2021 -0500 Also pre-process PHIs in range-of-stmt. PR tree-optimization/103464 * gimple-range.cc (gimple_ranger::prefill_name): Process phis also. (gimple_ranger::prefill_stmt_dependencies): Ditto.
