[Bug debug/102481] Incorrect source file path in debuginfo for assembly file specified with relative path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102481 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- This is a binutils bug (or feature dealing with dwarf5): ubuntu@ubuntu:/tmp/obj\# as -g -o test.o ../test.S ubuntu@ubuntu:/tmp/obj\# dwarfdump -i test.o .debug_info COMPILE_UNIT: < 0><0x000b> DW_TAG_compile_unit DW_AT_stmt_list 0x DW_AT_low_pc0x DW_AT_high_pc 0x0004 DW_AT_name ../test.S DW_AT_comp_dir /tmp/obj DW_AT_producer GNU AS 2.37 DW_AT_language DW_LANG_Mips_Assembler ubuntu@ubuntu:/tmp/obj\# as -g -o test.o ../test.S -gdwarf-5 ubuntu@ubuntu:/tmp/obj\# dwarfdump -i test.o .debug_info COMPILE_UNIT: < 0><0x000c> DW_TAG_compile_unit DW_AT_stmt_list 0x DW_AT_low_pc0x DW_AT_high_pc 0x0004 DW_AT_name test.S DW_AT_comp_dir /tmp/obj DW_AT_producer GNU AS 2.37 DW_AT_language DW_LANG_Mips_Assembler
[Bug debug/102481] New: Incorrect source file path in debuginfo for assembly file specified with relative path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102481 Bug ID: 102481 Summary: Incorrect source file path in debuginfo for assembly file specified with relative path Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: roc at ocallahan dot org Target Milestone: --- Steps to reproduce: $ cat > /tmp/test.S .global foo foo: ret $ cd /tmp/obj $ mkdir /tmp/obj $ gcc -g -c - o test.o ../test.S $ dwarfdump -i test.o I get UNIT: < 0><0x000c> DW_TAG_compile_unit DW_AT_stmt_list <.debug_line+0x> DW_AT_low_pc0x DW_AT_high_pc 1 DW_AT_name test.S DW_AT_comp_dir /tmp/obj DW_AT_producer GNU AS 2.37.50 DW_AT_language DW_LANG_Mips_Assembler This indicates the source file is at /tmp/obj/test.S, which is incorrect. If I call the assembler directly, I get correct output: $ as -g -o test.o ../test.S $ dwarfdump -i test.o UNIT: < 0><0x000b> DW_TAG_compile_unit DW_AT_stmt_list <.debug_line+0x> DW_AT_low_pc0x DW_AT_high_pc 0x0001 DW_AT_name ../test.S DW_AT_comp_dir /tmp/obj DW_AT_producer GNU AS 2.37.50 DW_AT_language DW_LANG_Mips_Assembler gcc version is 11.2.1 20210728 (Red Hat 11.2.1-1).
[Bug middle-end/59863] const array in function is placed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #7 from Andrew Pinski --- Confirmed.
[Bug c++/102049] Extend attribute deprecated to allow optional 2nd argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102049 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- It'd also be useful to have the compiler generate fixit hints to use the replacement, too, when that's possible
[Bug middle-end/59863] const array in function is placed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863 Andrew Pinski changed: What|Removed |Added CC||zhongyunde at huawei dot com --- Comment #6 from Andrew Pinski --- *** Bug 93102 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/93102] [optimization] is it legal to avoid accessing const local array from stack ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93102 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 59863. *** This bug has been marked as a duplicate of bug 59863 ***
[Bug debug/102442] Incorrect debug info for C89-style function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102442
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #2 from Eric Gallager ---
That's not a C89 function parameter, that's a K parameter, which was
outdated even in C89. GCC warns about it:
$ /usr/local/bin/gcc -c -Wall -Wextra -Wstrict-prototypes -Wimplicit
-Wold-style-definition -Wold-style-declaration -Wmissing-prototypes
-Wmissing-declarations -pedantic -Wconversion -Wdouble-promotion
-Wtraditional-conversion 102442.c
102442.c:4:7: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
4 | float fx(x) float x;
| ^~
102442.c: In function 'fx':
102442.c:4:7: warning: old-style function definition [-Wold-style-definition]
102442.c:6:14: warning: implicit conversion from 'float' to 'double' to match
other operand of binary expression [-Wdouble-promotion]
6 | return x + 1.0;
| ^
102442.c:6:14: warning: conversion from 'double' to 'float' may change value
[-Wfloat-conversion]
6 | return x + 1.0;
|~~^
102442.c: At top level:
102442.c:9:7: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
9 | float inita() { return 3.0; }
| ^
102442.c: In function 'inita':
102442.c:9:7: warning: old-style function definition [-Wold-style-definition]
102442.c: At top level:
102442.c:11:5: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
11 | int main()
| ^~~~
102442.c: In function 'main':
102442.c:11:5: warning: old-style function definition [-Wold-style-definition]
In file included from 102442.c:1:
102442.c:14:15: warning: implicit conversion from 'float' to 'double' when
passing argument to function [-Wdouble-promotion]
14 | assert(fx(a) == 4.0);
| ^
102442.c:14:18: warning: implicit conversion from 'float' to 'double' to match
other operand of binary expression [-Wdouble-promotion]
14 | assert(fx(a) == 4.0);
| ^~
102442.c:14:5: warning: passing argument 1 of '__builtin_expect' with different
width due to prototype [-Wtraditional-conversion]
14 | assert(fx(a) == 4.0);
| ^~
102442.c:14:5: warning: passing argument 2 of '__builtin_expect' with different
width due to prototype [-Wtraditional-conversion]
$
As does clang:
$ clang -c -Weverything 102442.c
warning: include location '/usr/local/include' is unsafe for cross-compilation
[-Wpoison-system-directories]
102442.c:6:14: warning: implicit conversion loses floating-point precision:
'double' to 'float' [-Wimplicit-float-conversion]
return x + 1.0;
~~ ~~^
102442.c:6:12: warning: implicit conversion increases floating-point precision:
'float' to 'double' [-Wdouble-promotion]
return x + 1.0;
^ ~
102442.c:4:7: warning: no previous prototype for function 'fx'
[-Wmissing-prototypes]
float fx(x) float x;
^
102442.c:4:1: note: declare 'static' if the function is not intended to be used
outside of this translation unit
float fx(x) float x;
^
static
102442.c:4:9: warning: this old-style function definition is not preceded by a
prototype [-Wstrict-prototypes]
float fx(x) float x;
^
102442.c:9:7: warning: no previous prototype for function 'inita'
[-Wmissing-prototypes]
float inita() { return 3.0; }
^
102442.c:9:1: note: declare 'static' if the function is not intended to be used
outside of this translation unit
float inita() { return 3.0; }
^
static
102442.c:9:12: warning: this old-style function definition is not preceded by a
prototype [-Wstrict-prototypes]
float inita() { return 3.0; }
^
102442.c:14:12: warning: implicit conversion increases floating-point
precision: 'float' to 'double' [-Wdouble-promotion]
assert(fx(a) == 4.0);
^ ~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/assert.h:93:25:
note: expanded from macro 'assert'
(__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e)
: (void)0)
^
102442.c:14:15: warning: implicit conversion increases floating-point
precision: 'float' to 'double' [-Wdouble-promotion]
assert(fx(a) == 4.0);
~~ ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/assert.h:93:25:
note: expanded from macro 'assert'
(__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e)
: (void)0)
^
9 warnings generated.
$
I think the warnings make it pretty clear that code like this needs to be
updated.
[Bug c/91092] Error on implicit function declarations by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #20 from Eric Gallager --- So, Apple turned on -Werror=implicit-function-declaration on by default for their version of clang that ships with macOS, and in response, the MacPorts project has added features to scan the config.log files of ports built with it for instances of -Werror=implicit-function-declaration and report them. As expected, it does indeed turn up a lot of results, but work is being done to fix them all, producing patches for the configure scripts in many cases. Upstream projects will just need to apply these patches in order to be ready.
[Bug c/88822] Strange inconsistency between types of qualified rvalues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88822 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||11.1.0 Resolution|--- |FIXED Target Milestone|--- |11.0 Known to fail||10.1.0 --- Comment #2 from Andrew Pinski --- Fixed in GCC 11+, most likely by r11-5188-g32934a4f45a.
[Bug c/86221] _Generic not match function return that has _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Note clang seems to have a bug for the const/volatile/restrict case even. Anyways invalid as explained in comment #1.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 Keywords||rejects-valid --- Comment #25 from Andrew Pinski --- Fixed for GCC 11 by the referenced revision in comment #23.
[Bug libstdc++/102480] std::regex fails to match ^ when match_prev_avail is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-09-24 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/102480] New: std::regex fails to match ^ when match_prev_avail is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480
Bug ID: 102480
Summary: std::regex fails to match ^ when match_prev_avail is
used
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 102445
Target Milestone: ---
#include
#include
int main() {
char str[] = "\na";
std::regex re("^a");
assert(std::regex_match(str + 1, str + 2, re));
using std::regex_constants::match_prev_avail;
assert(std::regex_match(str + 1, str + 2, re, match_prev_avail));
}
Both assertions should pass.
For the first match, the regex matches at the beginning of the input.
For the second match, the regex should also match because the previous
character is a line terminator.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
[Bug 102445] [meta-bug] std::regex issues
[Bug c/68764] C frontend does not fold away trivial expressions that refer to const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68764
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=66618,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=69960
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Andrew Pinski ---
Fixed for GCC 8 by r8-4755-gf9c59f7e9511 (aka PR 66618 and PR 69960).
Explicitly this part of c_fully_fold_internal:
/* Constants, declarations, statements, errors, and anything else not
counted as an expression cannot usefully be folded further at this
point. */
- if (!IS_EXPR_CODE_CLASS (kind)
- || kind == tcc_statement)
-return expr;
+ if (!IS_EXPR_CODE_CLASS (kind) || kind == tcc_statement)
+{
+ /* Except for variables which we can optimize to its initializer. */
+ if (VAR_P (expr) && !lval && (optimize || in_init))
+ {
+ ret = decl_constant_value (expr);
+ /* Avoid unwanted tree sharing between the initializer and current
+function's body where the tree can be modified e.g. by the
+gimplifier. */
+ if (ret != expr && TREE_STATIC (expr))
+ ret = unshare_expr (ret);
+ return ret;
+ }
+ return expr;
+}
[Bug c/94428] Reintroduce -Wzero-length-array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428 --- Comment #3 from Segher Boessenkool --- (In reply to Martin Sebor from comment #1) > With the introduction of -Wzero-length-bounds in GCC 10 (which, > incidentally, was added specifically to ease the adoption of the stricter > array bounds checking in GCC 10 by the kernel), adding a knob to diagnose > declarations of zero-length arrays sounds like a good idea to me. Should we warn about this by default even, for new enough C versions? So for -std=c99 and later? What about even for -std=gnu99 and later? Warning for arrays of length 1 is more dubious. If we really want that it should be a separate option?
[Bug c++/102479] segfault when deducing class template arguments for tuple with libc++-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102479 --- Comment #1 from Kent Ross --- The error also occurs in c++20 and c++17 modes.
[Bug c++/102479] New: segfault when deducing class template arguments for tuple with libc++-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102479
Bug ID: 102479
Summary: segfault when deducing class template arguments for
tuple with libc++-14
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: root.main at gmail dot com
Target Milestone: ---
Created attachment 51509
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51509=edit
processed source code of the example file that causes the crash
The expression `std::tuple(1)` causes a segfault when using recent iterations
of libc++.
Below is a summary of the commandline output of various attributes of my
machine and the failure at the end, and attached is the processed source file.
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 21.04
Release:21.04
Codename: hirsute
$ lscpu
Architecture:x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 36
On-line CPU(s) list: 0-35
Thread(s) per core: 2
Core(s) per socket: 18
Socket(s): 1
NUMA node(s):1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Core(TM) i9-7980XE CPU @ 2.60GHz
Stepping:4
CPU MHz: 1200.000
CPU max MHz: 4500.
CPU min MHz: 1200.
BogoMIPS:5199.98
Virtualization: VT-x
L1d cache: 576 KiB
L1i cache: 576 KiB
L2 cache:18 MiB
L3 cache:24.8 MiB
NUMA node0 CPU(s): 0-35
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional
cache flushes, SMT vulnerable
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled
via prctl and seccomp
Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and
__user pointer sanitization
Vulnerability Spectre v2:Mitigation; Full generic retpoline, IBPB
conditional, IBRS_FW, STIBP conditional, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe
popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch
cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti ssbd mba ibrs ibpb stibp
tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2
smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap
clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1
xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln
pts md_clear flush_l1d
$ dpkg -l | grep libc++-14-dev
ii libc++-14-dev:amd64
1:14~++20210915104425+934e2f695e18-1~exp1~20210915085239.659 amd64
LLVM C++ Standard library (development files)
$ readlink -f /usr/include/c++/v1
/usr/lib/llvm-14/include/c++/v1
$ dpkg -l | grep g++-11
ii g++-1111.1.0-1ubuntu1~21.04
amd64GNU C++ compiler
$ g++-11 --version
g++-11 (Ubuntu 11.1.0-1ubuntu1~21.04) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat misc/scratch.cc
#include
int main(int, char**) {
auto t = std::tuple(1);
return 0;
}
$ g++-11 -nostdinc++ -v -I /usr/include/c++/v1
-D_GNU_SOURCE misc/scratch.cc -std=c++23 -Wall -Wextra
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with:
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447
--- Comment #2 from Jonathan Wakely ---
Actually, this might not be a bug.
We have this comment in regex_compiler.tcc
// POSIX doesn't allow '-' as a start-range char (say [a-z--0]),
// except when the '-' is the first or last character in the bracket
// expression ([--0]). ECMAScript treats all '-' after a range as a
// normal character. Also see above, where _M_expression_term gets
called.
//
// As a result, POSIX rejects [-], but ECMAScript doesn't.
// Boost (1.57.0) always uses POSIX style even in its ECMAScript syntax.
// Clang (3.5) always uses ECMAScript style even in its POSIX syntax.
//
// It turns out that no one reads BNFs ;)
So [\w-a] is valid for the ECMAScript syntax and is equivalent to POSIX
[-_[:alnum:]].
You can confirm this using your browser's javascript console, where this will
print true:
RegExp('[\\w-a]').test('-')
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 Giulio Benetti changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Giulio Benetti --- Oh sorry, I've just found out now that loop.c takes very very long time to build(it's 7M of .c source file) and Buildroot autobuilder times out. We need to retrim timeout value there. Sorry for the noise, I close this bug as RESOLVED->INVALID. Best regards
[Bug c++/91292] Mangler incorrectly handles negative numbers in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292
--- Comment #7 from Richard Smith ---
(In reply to Patrick Palka from comment #3)
> Hmm, but according to
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling.literal the
> mangling of a negative integer literal is prefixed with "n",
There is no such thing as a negative integer literal.
The ABI document says "negative integer *values* are preceded with "n""; this
case is reached when mangling fully-resolved template arguments via the
::=
production, not when mangling an instantiation-dependent expression. For
example, given
template struct X {};
template void f(X, X<-1>) {}
template void f<1>(X<-1>, X<-1>);
the proper mangling is
_Z1fILi1EEv1XIXmlT_ngLi1EEES0_ILin1EE
using ngLi1E for the instantiation-dependent expression -1 and Lin1E for the
non-instantiation-dependent value -1.
(In reply to Patrick Palka from comment #4)
> And if -(1) is to be mangled the same as -1, then shouldn't
>
> template
> typename std::enable_if<(int)sizeof(T) >= -(1), int>::type size1(T *t);
>
> template
> typename std::enable_if<(int)sizeof(T) >= -1, int>::type size1(T *t);
>
> be considered two declarations of the same function? But IIUC that would
> contradict [temp.over.link]p5, which says
>
> Two expressions involving template parameters are considered equivalent if
> two function definitions containing the expressions would satisfy the
> one-definition rule
>
> but IIUC the one-definition rule fails here because -1 is not the same
> (token-wise) as -(1).
These declarations are functionally-equivalent but not equivalent, so a program
is not permitted to contain both. That language rule exists in order to allow
implementations to do things like ignore parentheses in mangling, as the
Itanium C++ ABI does.
Note that parentheses are never mangled (except for a weird corner case
involving pointers to members), so if your argument were correct it would apply
very broadly. For example, that argument would imply that -1 and (-1) would
need different manglings.
[Bug libstdc++/84110] Null character in regex throws std::regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c++/98216] [C++20] template mangling for double template argument is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 Emmanuel Le Trong changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Emmanuel Le Trong --- Fixed, thank you.
[Bug rtl-optimization/102478] [9/10/11/12 Regression] during RTL pass: ce3: ICE: in gen_reg_rtx, at emit-rtl.c:1167 with -O2 -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102478 Andrew Pinski changed: What|Removed |Added Component|target |rtl-optimization CC||pinskia at gcc dot gnu.org Target Milestone|--- |9.5
[Bug c/94428] Reintroduce -Wzero-length-array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428 --- Comment #2 from Kees Cook --- Note that this needs a struct attribute that will allow structs to be excluded from the diagnostic (since the kernel needs to deal with legacy UAPI headers forever).
[Bug target/102478] New: [9/10/11/12 Regression] during RTL pass: ce3: ICE: in gen_reg_rtx, at emit-rtl.c:1167 with -O2 -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102478 Bug ID: 102478 Summary: [9/10/11/12 Regression] during RTL pass: ce3: ICE: in gen_reg_rtx, at emit-rtl.c:1167 with -O2 -fno-if-conversion 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: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: powerpc64le-unknown-linux-gnu Created attachment 51508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51508=edit reduced testcase Compiler output: $ powerpc64le-unknown-linux-gnu-gcc -O2 -fno-if-conversion testcase.c testcase.c: In function 'foo': testcase.c:6:45: warning: division by zero [-Wdiv-by-zero] 6 | c |= __builtin_expect (65535 / a, 0) && 0 / 0; | ^ during RTL pass: ce3 testcase.c:8:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1167 8 | } | ^ 0x63b466 gen_reg_rtx(machine_mode) /repo/gcc-trunk/gcc/emit-rtl.c:1167 0xba8069 force_reg(machine_mode, rtx_def*) /repo/gcc-trunk/gcc/explow.c:676 0xe48e63 prepare_cmp_insn /repo/gcc-trunk/gcc/optabs.c:4396 0xe4a09f gen_cond_trap(rtx_code, rtx_def*, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/optabs.c:5851 0x19548e7 find_cond_trap /repo/gcc-trunk/gcc/ifcvt.c:4721 0x19548e7 find_if_header /repo/gcc-trunk/gcc/ifcvt.c:4346 0x19548e7 if_convert /repo/gcc-trunk/gcc/ifcvt.c:5475 0x195565d execute /repo/gcc-trunk/gcc/ifcvt.c:5628 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ powerpc64le-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-3885-20210924181655-g71f96511084-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu --with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-3885-20210924181655-g71f96511084-checking-yes-rtl-df-extra-powerpc64le Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210924 (experimental) (GCC)
[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500 --- Comment #5 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #4) > Well Martin suggested it should include the array length, but I'm content > with not saying "chars". What is interesting is the C++ front-end with that change got it right (see PR 84501). I have not looked to see if the array length can be there or not.
[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500 --- Comment #4 from Jonathan Wakely --- Well Martin suggested it should include the array length, but I'm content with not saying "chars".
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-24 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500 --- Comment #3 from Andrew Pinski --- We get in GCC 10+ (r10-464-ga9c697b88395a, same revision which fixed PR 84501): :4:18: warning: initializer-string for array of 'int' is too long 4 | wchar_t w[3] = L"abcd"; | ^~~ :5:21: warning: initializer-string for array of 'short unsigned int' is too long 5 | char16_t u16[3] = u"abcd"; | ^~~ :6:21: warning: initializer-string for array of 'unsigned int' is too long 6 | char32_t u32[3] = U"abcd"; | ^~~ So fixed enough?
[Bug c++/84501] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84501 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- In GCC 10+ we get now (r10-464-ga9c697b88395): : In function 'int main()': :4:18: error: initializer-string for 'wchar_t [3]' is too long [-fpermissive] 4 | wchar_t w[3] = L"abcd"; | ^~~ :5:21: error: initializer-string for 'char16_t [3]' is too long [-fpermissive] 5 | char16_t u16[3] = u"abcd"; | ^~~ :6:21: error: initializer-string for 'char32_t [3]' is too long [-fpermissive] 6 | char32_t u32[3] = U"abcd"; | ^~~ So fixed.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 --- Comment #15 from David Binderman --- Since this bug depends on the setting of -march, I tried out all the possible legal settings of that value. alderlake amdfam10 during GIMPLE pass: aprefetch athlon-fx during GIMPLE pass: aprefetch athlon64 during GIMPLE pass: aprefetch athlon64-sse3 during GIMPLE pass: aprefetch atom barcelona during GIMPLE pass: aprefetch bdver1 during GIMPLE pass: aprefetch bdver2 during GIMPLE pass: aprefetch bdver3 during GIMPLE pass: aprefetch bdver4 during GIMPLE pass: aprefetch bonnell broadwell btver1 during GIMPLE pass: aprefetch btver2 during GIMPLE pass: aprefetch cannonlake cascadelake cooperlake core-avx-i core-avx2 core2 corei7 corei7-avx eden-x2 during GIMPLE pass: aprefetch eden-x4 during GIMPLE pass: aprefetch goldmont goldmont-plus haswell celake-client icelake-server ivybridge k8 during GIMPLE pass: aprefetch k8-sse3 during GIMPLE pass: aprefetch knl knm nano during GIMPLE pass: aprefetch nano-1000 during GIMPLE pass: aprefetch nano-2000 during GIMPLE pass: aprefetch nano-3000 during GIMPLE pass: aprefetch nano-x2 during GIMPLE pass: aprefetch nano-x4 during GIMPLE pass: aprefetch native during GIMPLE pass: aprefetch nehalem nocona opteron during GIMPLE pass: aprefetch opteron-sse3 during GIMPLE pass: aprefetch rocketlake sandybridge sapphirerapids silvermont skylake skylake-avx512 slm tigerlake tremont westmere x86-64 x86-64-v2 x86-64-v3 x86-64-v4 znver1 znver2 znver3 I generated this list with this command: $ for i in `cat ~/arch.list`; do echo $i; /home/dcb/gcc/results/bin/gcc -c -O3 -march=$i bug760.c 2>&1 | fgrep GIMPLE ; done
[Bug rtl-optimization/102441] [10/11/12 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441
--- Comment #3 from Jakub Jelinek ---
Perhaps we need something like:
--- gcc/var-tracking.c.jj 2021-05-04 21:02:24.196799586 +0200
+++ gcc/var-tracking.c 2021-09-24 19:23:16.420154828 +0200
@@ -6133,7 +6133,9 @@ add_stores (rtx loc, const_rtx expr, voi
{
if (preserve)
preserve_value (v);
- return;
+ mo.type = MO_CLOBBER;
+ mo.u.loc = loc;
+ goto log_and_return;
}
nloc = replace_expr_with_values (oloc);
but am not 100% sure if that is the right thing to do in all cases.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #11 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:84cccff60a978174271a30042bf7841d2ae436eb commit r12-3884-g84cccff60a978174271a30042bf7841d2ae436eb Author: Harald Anlauf Date: Fri Sep 24 19:10:15 2021 +0200 Fortran - improve checking for intrinsics allowed in constant expressions gcc/fortran/ChangeLog: PR fortran/102458 * expr.c (is_non_constant_intrinsic): Check for intrinsics excluded in constant expressions (F2018:10.1.2). (gfc_is_constant_expr): Use that check. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458.f90: New test.
[Bug fortran/101333] gfortran fails to enforce C711 on assumed-type actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333 --- Comment #1 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:2364250eccc389a5f9820ac55f8260d34f229e73 commit r12-3883-g2364250eccc389a5f9820ac55f8260d34f229e73 Author: Sandra Loosemore Date: Thu Sep 23 15:00:43 2021 -0700 Fortran: Add missing diagnostic for F2018 C711 (TS29113 C407c) 2021-09-24 Sandra Loosemore PR fortran/101333 gcc/fortran/ * interface.c (compare_parameter): Enforce F2018 C711. gcc/testsuite/ * gfortran.dg/c-interop/c407c-1.f90: Remove xfails.
[Bug c++/98216] [C++20] template mangling for double template argument is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:34947d4e97ee72b26491cfe5ff4fa8258fadbe95 commit r12-3882-g34947d4e97ee72b26491cfe5ff4fa8258fadbe95 Author: Patrick Palka Date: Fri Sep 24 12:36:26 2021 -0400 real: fix encoding of negative IEEE double/quad values [PR98216] In encode_ieee_double/quad, the assignment unsigned long WORD = r->sign << 31; is intended to set the 31st bit of WORD whenever the sign bit is set. But on LP64 hosts it also unintentionally sets the upper 32 bits of WORD, because r->sign gets promoted from unsigned:1 to int and then the result of the shift (equal to INT_MIN) gets sign extended from int to long. In the C++ frontend, this bug causes incorrect mangling of negative floating point values because the output of real_to_target called from write_real_cst unexpectedly has the upper 32 bits of this word set, which the caller doesn't mask out. This patch fixes this by avoiding the unwanted sign extension. Note that r0-53976 fixed the same bug in encode_ieee_single long ago. PR c++/98216 PR c++/91292 gcc/ChangeLog: * real.c (encode_ieee_double): Avoid unwanted sign extension. (encode_ieee_quad): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-float2.C: New test.
[Bug c++/91292] Mangler incorrectly handles negative numbers in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:34947d4e97ee72b26491cfe5ff4fa8258fadbe95 commit r12-3882-g34947d4e97ee72b26491cfe5ff4fa8258fadbe95 Author: Patrick Palka Date: Fri Sep 24 12:36:26 2021 -0400 real: fix encoding of negative IEEE double/quad values [PR98216] In encode_ieee_double/quad, the assignment unsigned long WORD = r->sign << 31; is intended to set the 31st bit of WORD whenever the sign bit is set. But on LP64 hosts it also unintentionally sets the upper 32 bits of WORD, because r->sign gets promoted from unsigned:1 to int and then the result of the shift (equal to INT_MIN) gets sign extended from int to long. In the C++ frontend, this bug causes incorrect mangling of negative floating point values because the output of real_to_target called from write_real_cst unexpectedly has the upper 32 bits of this word set, which the caller doesn't mask out. This patch fixes this by avoiding the unwanted sign extension. Note that r0-53976 fixed the same bug in encode_ieee_single long ago. PR c++/98216 PR c++/91292 gcc/ChangeLog: * real.c (encode_ieee_double): Avoid unwanted sign extension. (encode_ieee_quad): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-float2.C: New test.
[Bug c++/91292] Mangler incorrectly handles negative numbers in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98216 --- Comment #5 from Patrick Palka --- The wrong mangling of floating point numbers is also being tracked at PR98216
[Bug c++/91292] Mangler incorrectly handles negative numbers in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292 --- Comment #4 from Patrick Palka --- And if -(1) is to be mangled the same as -1, then shouldn't template typename std::enable_if<(int)sizeof(T) >= -(1), int>::type size1(T *t); template typename std::enable_if<(int)sizeof(T) >= -1, int>::type size1(T *t); be considered two declarations of the same function? But IIUC that would contradict [temp.over.link]p5, which says Two expressions involving template parameters are considered equivalent if two function definitions containing the expressions would satisfy the one-definition rule but IIUC the one-definition rule fails here because -1 is not the same (token-wise) as -(1).
[Bug c++/91292] Mangler incorrectly handles negative numbers in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91292 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- > According to http://itanium-cxx-abi.github.io/cxx-abi/abi.html#expressions , > a negative number isn't treated as a negative literal; it is a negated > number. This means that it is mangled as though it were positive, and then > its negation is mangled. So -1 and -(1) are treated the same. Hmm, but according to http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling.literal the mangling of a negative integer literal is prefixed with "n", and according to http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.operator-name the mangling of - is prefixed with "ng". So I don't see why -1 and -(1) should be given the same mangling. ISTM GCC is already getting the mangling right.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #8 from Richard Earnshaw --- I suspect go has a similar issue, but it looks as though c, c++, fortran and d are all ok.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 --- Comment #2 from Bill Schmidt --- Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580235.html.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #7 from Richard Earnshaw --- (In reply to Richard Earnshaw from comment #6) > So I think we need a way of checking that this won't fail before we call it. > > Any idea? > > tree type = lang_hooks.types.type_for_size (ilen * 8, 1); Or alternatively, perhaps this should just return NULL if there is no such type, we already test for that. In which case this is a bug in the Ada type_for_size routine.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #6 from Richard Earnshaw --- So I think we need a way of checking that this won't fail before we call it. Any idea? tree type = lang_hooks.types.type_for_size (ilen * 8, 1);
[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit pointer size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147 --- Comment #8 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:51ca05031959d3accffe873e87d4bc4fbd22e9e9 commit r12-3881-g51ca05031959d3accffe873e87d4bc4fbd22e9e9 Author: Vladimir N. Makarov Date: Fri Sep 24 10:06:45 2021 -0400 Make profitability calculation of RA conflict presentations independent of host compiler type sizes. [PR102147] gcc/ChangeLog: 2021-09-24 Vladimir Makarov PR rtl-optimization/102147 * ira-build.c (ira_conflict_vector_profitable_p): Make profitability calculation independent of host compiler pointer and IRA_INT_BITS sizes.
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 --- Comment #5 from rdapp at linux dot ibm.com --- git bisect bad5f6a6c91d7c592cb49f7c519f289777eac09bb74 is the first bad commit commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74 Author: Richard Earnshaw Date: Fri Sep 3 17:06:15 2021 +0100 gimple: allow more folding of memcpy [PR102125] [..]
[Bug debug/102442] Incorrect debug info for C89-style function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102442 Joseph C. Sible changed: What|Removed |Added CC||josephcsible at gmail dot com --- Comment #1 from Joseph C. Sible --- I wonder if this is related to fx actually being a float(double) and not a float(float) as it appears to be.
[Bug target/102477] ICE: in emit_move_insn, at expr.c:4026 at -Og with __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Such conversion is just reinterpretation of the bits in the same mode, nop at RTL level. So it should just work.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|REOPENED|NEW --- Comment #14 from Richard Biener --- Confirmed.
[Bug target/102477] ICE: in emit_move_insn, at expr.c:4026 at -Og with __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-09-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. We have _2 = (vector(16) signed int) v.0_1; where v.0_1 is vector(16) unsigned int. So appearantly we have an optab for that but it doesn't work here.
[Bug target/102473] [12 Regression] 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473 --- Comment #4 from Hongtao.liu --- (In reply to Hongtao.liu from comment #2) > (In reply to Richard Biener from comment #1) > > Looks like at least on Zen movs[hl]dup is on the integer domain so we'l see > > a domain crossing penalty here(?). But since this is a generic arch/tuning > > regression the SSE2 code path should be what matters - on the committed > > testcase I see > > > > foo: > > .LFB572: > > .cfi_startproc > > pxor%xmm0, %xmm0 > > addss (%rdi), %xmm0 > > addss 4(%rdi), %xmm0 > > addss 8(%rdi), %xmm0 > > addss 12(%rdi), %xmm0 > > ret > > > > where it seems that the vectorizer doesn't pick up the reduction pattern. > > > Guess you're use O3, -ffast-math is needed for v4sf reduction > https://godbolt.org/z/sjf4Pncna > > And original code also have movhlps. > > BTW: i can't reproduce the regression on CLX/coffelake for one copy run. > options are below > > 521.wrf_r: "gfortran -m64" (in FC) "gcc -m64" (in CC) > "gfortran -m64" (in LD) > "-fconvert=big-endian -std=legacy -fno-inline-arg-packing" (in > FPORTABILITY) > "-mtune=generic -Ofast -mfpmath=sse -fno-associative-math" (in > OPTIMIZE) Reproduced after removing -fno-associative-math.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #6 from Hongtao.liu --- (In reply to Hongtao.liu from comment #5) > (gdb) p direct_internal_fn_supported_p (IFN_CEIL, type, OPTIMIZE_FOR_BOTH) > $110 = false > > (gdb) p direct_internal_fn_supported_p (IFN_SQRT, type, OPTIMIZE_FOR_BOTH) > $111 = true > > hmm, why? Hmm, Because in ix86_optab_supported_p, we have case rint_optab: if ((SSE_FLOAT_MODE_P (mode1) && TARGET_SSE_MATH && !flag_trapping_math && !TARGET_SSE4_1)) return opt_type == OPTIMIZE_FOR_SPEED; return true; case floor_optab: case ceil_optab: case btrunc_optab: if ((SSE_FLOAT_MODE_P (mode1) && TARGET_SSE_MATH && !flag_trapping_math && TARGET_SSE4_1) return true; return opt_type == OPTIMIZE_FOR_SPEED;
[Bug rtl-optimization/102441] [10/11/12 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- So, I see 2 changes since 7-ish. The first one is in r8-5241-g8697bf9f46f36168ddba5752db582e673e3cbe8c which added statement frontiers and therefore moved where the breakpoint is actually placed. Before/after that commit, the location info for x seems correct, first %rdi and at the insn setting %rdi changing to entry_value(%rdi). But entry_value(%rdi) doesn't seem to be usable in this case, because main tail calls foo and so main is out of the backtrace, and the outer frame is __libc_start_main which is in assembly, so the debugger can't try to reconstruct the tail call path. So, before r8-5241 the debugger prints for x at line 6 10 (#c1), at or after it it prints . The next change is r10-7665-g33c45e51b4914008064d9b77f2c1fc0eea1ad060 and that causes wrong-debug for this case. It isn't immediately clear to me why, because %rdi certainly isn't sp based, but I'll need to debug.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #5 from Hongtao.liu --- (gdb) p direct_internal_fn_supported_p (IFN_CEIL, type, OPTIMIZE_FOR_BOTH) $110 = false (gdb) p direct_internal_fn_supported_p (IFN_SQRT, type, OPTIMIZE_FOR_BOTH) $111 = true hmm, why?
[Bug ada/102450] GCC error: in set_min_and_max_values_for_integral_type, at stor-layout.c:2851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450 rdapp at linux dot ibm.com changed: What|Removed |Added CC||rdapp at linux dot ibm.com --- Comment #4 from rdapp at linux dot ibm.com --- Also happens on s390 with -m31 in stage 3: /home/rdapp/projects/gcc/build/./gcc/xgcc -B/home/rdapp/projects/gcc/build/./gcc/ -B/home/rdapp/gcc-fail/s390x-ibm-linux-gnu/bin/ -B/home/rdapp/gcc-fail/s390x-ibm-linux-gnu/lib/ -isystem /home/rdapp/gcc-fail/s390x-ibm-linux-gnu/include -isystem /home/rdapp/gcc-fail/s390x-ibm-linux-gnu/sys-include -fchecking=1 -c -g -O2 -m31 -fPIC -W -Wall -gnatpg -nostdinc -m31 g-sehash.adb -o g-sehash.o during GIMPLE pass: lower +===GNAT BUG DETECTED==+ | 12.0.0 20210923 (experimental) (s390x-ibm-linux-gnu) GCC error: | | in set_min_and_max_values_for_integral_type, at stor-layout.c:2851 | | Error detected around g-sehash.adb:98:4 | | Compiling g-sehash.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). system.ads g-sehash.adb g-sehash.ads g-sechas.ads gnat.ads ada.ads a-stream.ads interfac.ads g-bytswa.ads a-sttebu.ads a-string.ads a-stuten.ads unchconv.ads s-exctab.ads s-stalib.ads a-unccon.ads a-tags.ads s-stoele.ads s-soflin.ads a-except.ads s-parame.ads s-traent.ads s-secsta.ads s-stache.ads s-putima.ads s-unstyp.ads g-sechas.adb s-stoele.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:414 precision=512 though, backtrace:#0 set_min_and_max_values_for_integral_type (type=type@entry=0x3fffb7c3000, precision=512, sgn=sgn@entry=UNSIGNED) at ../../gcc/stor-layout.c:2851 #1 0x01f141a8 in fixup_unsigned_type (type=type@entry=0x3fffb7c3000) at ../../gcc/stor-layout.c:2885 #2 0x01f14248 in make_unsigned_type (precision=) at ../../gcc/stor-layout.c:2708 #3 0x013c0698 in gnat_type_for_size (precision=, unsignedp=) at ../../gcc/ada/gcc-interface/utils.c:3670 #4 0x01b6584e in gimple_fold_builtin_memory_op (gsi=gsi@entry=0x3ffded8, dest=0x3fffb76f760, src=0x3fffb76e510, code=code@entry=BUILT_IN_MEMMOVE) at ../../gcc/gimple-fold.c:1004 #5 0x01b67a9e in gimple_fold_builtin (gsi=0x3ffded8) at ../../gcc/gimple.h:3297 #6 gimple_fold_call (gsi=gsi@entry=0x3ffded8, inplace=inplace@entry=false) at ../../gcc/gimple-fold.c:5588 #7 0x01b69732 in fold_stmt_1 (gsi=gsi@entry=0x3ffded8, inplace=inplace@entry=false, valueize=valueize@entry=0x1b500b0 ) at ../../gcc/gimple-fold.c:6290 #8 0x01b6b260 in fold_stmt (gsi=gsi@entry=0x3ffded8) at
[Bug target/102477] New: ICE: in emit_move_insn, at expr.c:4026 at -Og with __builtin_shufflevector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477
Bug ID: 102477
Summary: ICE: in emit_move_insn, at expr.c:4026 at -Og with
__builtin_shufflevector()
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: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 51507
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51507=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og testcase.c
testcase.c: In function 'foo':
testcase.c:10:1: warning: AVX512F vector return without AVX512F enabled changes
the ABI [-Wpsabi]
10 | {
| ^
during RTL pass: expand
testcase.c:9:1: internal compiler error: in emit_move_insn, at expr.c:4026
9 | foo (void)
| ^~~
0x6be049 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.c:4026
0xe3f43a expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:4006
0xe3f43a expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4040
0xe4555a expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6082
0xe47207 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-3878-20210924101619-g710c6ab4ad5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-3878-20210924101619-g710c6ab4ad5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210924 (experimental) (GCC)
[Bug d/102476] New: d: Options -fmain and -fno-druntime do not work together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102476 Bug ID: 102476 Summary: d: Options -fmain and -fno-druntime do not work together Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- The option `-fmain' reads in a __main.di module from D runtime that defines an extern(D) main function. This causes link-time errors when building without D runtime.
[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017 --- Comment #3 from Christophe Lyon --- I made a typo in my description of the bug, it should read: fenv support is NOW enabled.
[Bug target/102475] New: incorrect definition of "normal" long doubles in libgcc/config/rs6000/ibm-ldouble-format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102475
Bug ID: 102475
Summary: incorrect definition of "normal" long doubles in
libgcc/config/rs6000/ibm-ldouble-format
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
In libgcc/config/rs6000/ibm-ldouble-format as seen at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/ibm-ldouble-format;hb=HEAD
I can read:
A long double can represent any value of the form
s * 2^e * sum(k=0...105: f_k * 2^(-k))
where 's' is +1 or -1, 'e' is between 1022 and -968 inclusive, f_0 is
1, and f_k for k>0 is 0 or 1. These are the 'normal' long doubles.
By "These are *the* 'normal' long doubles." I understand that the other long
double values are not 'normal' long doubles. This contradicts the following
definition in gcc/builtins.c:
/* isnormal(x) -> isgreaterequal(fabs(x),DBL_MIN) &
islessequal(fabs(x),DBL_MAX). */
and the implementation. The following is a test I had posted to comp.std.c on
2021-07-30 (thread "isnormal and non-FP values: possible defect"):
Here's a test program for long double, which shows the issue on PowerPC. Here,
1 + 2^(-120) is exactly representable as a double-double number (the exact sum
of 1 and 2^(-120), which are both double-precision numbers). This is verified
by the output of x - 1, which gives 2^(-120) instead of 0.
--
#include
#include
#include
int main (void)
{
volatile long double x = 1 + 0x1.p-120L;
int c;
printf ("LDBL_MANT_DIG = %d\n", (int) LDBL_MANT_DIG);
printf ("x - 1 = %La\n", x - 1);
c = fpclassify (x);
printf ("fpclassify(x) = %s\n",
c == FP_NAN ? "FP_NAN" :
c == FP_INFINITE ? "FP_INFINITE" :
c == FP_ZERO ? "FP_ZERO" :
c == FP_SUBNORMAL ? "FP_SUBNORMAL" :
c == FP_NORMAL ? "FP_NORMAL" : "unknown");
printf ("isfinite/isnormal/isnan/isinf(x) = %d/%d/%d/%d\n",
isfinite (x), isnormal (x), isnan (x), isinf (x));
return 0;
}
--
I get the following result:
LDBL_MANT_DIG = 106
x - 1 = 0x1p-120
fpclassify(x) = FP_NORMAL
isfinite/isnormal/isnan/isinf(x) = 1/1/0/0
So x is a number with more than the 106-bit precision of normal numbers, and
both fpclassify(x) and isnormal(x) regard it as a "normal number".
In the CFP group, it seems that it is currently agreed that "normal number"
should match the current gcc/builtins.c definition and implementation. Hence
the current definition in libgcc/config/rs6000/ibm-ldouble-format should be
regarded as incorrect.
Note: about another error in this file, see PR94073.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #13 from David Binderman ---
The code in comment 8 still seems to fail:
$ /home/dcb/gcc/results/bin/gcc -c -O3 -w -march=bdver2 bug760.c
bug760.c: In function ‘Gif_ClipImage’:
bug760.c:3:1: error: type mismatch in binary expression
3 | Gif_ClipImage() {
| ^
unsigned int
int
int
_18 = Gif_ClipImage_gfi_1.0_1 + -1;
bug760.c:3:1: error: type mismatch in binary expression
unsigned int
int
int
_12 = Gif_ClipImage_gfi_1.0_1 + -1;
during GIMPLE pass: aprefetch
bug760.c:3:1: internal compiler error: verify_gimple failed
0xdac31a verify_gimple_in_cfg(function*, bool)
../../trunk.git/gcc/tree-cfg.c:5576
$ /home/dcb/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20210924/libexec/gcc/x86_64-pc-linux-g
nu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.git/configure --prefix=/home/dcb/gcc/results.20210924
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=29c928
57039d0a10 --enable-checking=df,extra,fold,rtl,yes
--enable-languages=c,c++,fort
ran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210924 (experimental) (29c92857039d0a10)
[Bug fortran/62226] Encode CPP options in lang.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62226 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- I am not sure whether the original issue still exists. Fortran now uses a lot of the common machinery and also seems to handle CPP() well. Thus, is this now fixed/superseded by the recent and not so recent developments or is something still needed?
[Bug fortran/56659] Segfault due to missing libcpp error handler for "gfortran -cpp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tobias Burnus --- I think this issue is already fixed for a while. An issue related to the callback init coming too late for libcpp / incpath.c's call has been fixed by the first of the second commit in PR 55534 – However, for the issue reported in this PR, the callbacks were already initialized before the PR55534 fix. Hence close as FIXED.
[Bug target/102473] [12 Regression] 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
(In reply to Hongtao.liu from comment #2)
> (In reply to Richard Biener from comment #1)
> > Looks like at least on Zen movs[hl]dup is on the integer domain so we'l see
> > a domain crossing penalty here(?). But since this is a generic arch/tuning
> > regression the SSE2 code path should be what matters - on the committed
> > testcase I see
> >
> > foo:
> > .LFB572:
> > .cfi_startproc
> > pxor%xmm0, %xmm0
> > addss (%rdi), %xmm0
> > addss 4(%rdi), %xmm0
> > addss 8(%rdi), %xmm0
> > addss 12(%rdi), %xmm0
> > ret
> >
> > where it seems that the vectorizer doesn't pick up the reduction pattern.
> >
> Guess you're use O3, -ffast-math is needed for v4sf reduction
> https://godbolt.org/z/sjf4Pncna
I was looking at the testcase as compiled by the testsuite.
It seems that adding __attribute__((optimize("tree-vectorize"))) makes the
loop no longer vectorized as it at the moment cancels -ffast-math.
IIRC when Martin commits his optimize() re-org it will no longer do that.
[Bug debug/87726] -fdebug-prefix-map doesn't work with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726 Richard Biener changed: What|Removed |Added Known to work||10.3.0, 11.2.1, 7.5.0, ||9.3.1 Status|NEW |WAITING --- Comment #2 from Richard Biener --- It works fine for me with GCC 7, 9, 10 and 11 on x86_64-linux, not sure which version Mark used to reproduce. Can you confirm it now works?
[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661 --- Comment #10 from Antony Polukhin --- Any progress? Multiple compilers already eliminate the atexit call. Moreover, some of the compilers even eliminate the guard variable after that https://godbolt.org/z/dbdfMrroa Note that the atexit elimination would benefit the libstdc++, as the latter now uses a bunch of constant_init instances that have empty destructor in libstdc++-v3/src/c++17/memory_resource.cc and libstdc++-v3/src/c++11/system_error.cc . It would be possible to eliminate the atexit calls for those cases and speedup startup times https://godbolt.org/z/MKaWKevzq
[Bug target/102473] [12 Regression] 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473 --- Comment #2 from Hongtao.liu --- (In reply to Richard Biener from comment #1) > Looks like at least on Zen movs[hl]dup is on the integer domain so we'l see > a domain crossing penalty here(?). But since this is a generic arch/tuning > regression the SSE2 code path should be what matters - on the committed > testcase I see > > foo: > .LFB572: > .cfi_startproc > pxor%xmm0, %xmm0 > addss (%rdi), %xmm0 > addss 4(%rdi), %xmm0 > addss 8(%rdi), %xmm0 > addss 12(%rdi), %xmm0 > ret > > where it seems that the vectorizer doesn't pick up the reduction pattern. > Guess you're use O3, -ffast-math is needed for v4sf reduction https://godbolt.org/z/sjf4Pncna And original code also have movhlps. BTW: i can't reproduce the regression on CLX/coffelake for one copy run. options are below 521.wrf_r: "gfortran -m64" (in FC) "gcc -m64" (in CC) "gfortran -m64" (in LD) "-fconvert=big-endian -std=legacy -fno-inline-arg-packing" (in FPORTABILITY) "-mtune=generic -Ofast -mfpmath=sse -fno-associative-math" (in OPTIMIZE) "-fno-stack-arrays" (in EXTRA_OPTIMIZE) "-Wl,-z,muldefs" (in EXTRA_LDFLAGS) > /home/rguenther/src/gcc2/gcc/testsuite/gcc.target/i386/sse2-pr101059.c:20:21: > note: vect_is_simple_use: vectype vector(4) float > /home/rguenther/src/gcc2/gcc/testsuite/gcc.target/i386/sse2-pr101059.c:20:21: > missed: reduc op not supported by target.
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 --- Comment #16 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:204f56aa65d2496e9f7db86c4aa37d42a336fc5b commit r12-3877-g204f56aa65d2496e9f7db86c4aa37d42a336fc5b Author: Tobias Burnus Date: Fri Sep 24 09:30:51 2021 +0200 Fortran: Improve file-reading error diagnostic [PR55534] PR fortran/55534 gcc/fortran/ChangeLog: * scanner.c (load_file): Return void, call (gfc_)fatal_error for all errors. (include_line, include_stmt, gfc_new_file): Remove exit call for failed load_file run. gcc/testsuite/ChangeLog: * gfortran.dg/include_9.f90: Add dg-prune-output. * gfortran.dg/include_23.f90: New test. * gfortran.dg/include_24.f90: New test.
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 --- Comment #5 from Richard Biener --- On the GCC 11 branch head I cannot reproduce this with a x86_64-linux -> m68k-linux cross cc1, using -O2 -fwrapv -fPIC -g2 -Wno-unused-result -Wsign-compare -Wall Can you clarify that it is the compiler that enters an infinite loop rather than the object being miscompiled and python-uvloop entering an infinite loop? Can you also please quote the output of the compiler-command when you add -v to the command-line that causes the hang? In particular the line showing the cc1 execution is useful. Note I did not test GCC 11.2.0 exactly.
[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/102473] [12 Regression] 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 Last reconfirmed||2021-09-24 Summary|521.wrf_r 5% slower at |[12 Regression] 521.wrf_r |-Ofast and generic x86_64 |5% slower at -Ofast and |tuning after|generic x86_64 tuning after |r12-3426-g8f323c712ea76c|r12-3426-g8f323c712ea76c Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Looks like at least on Zen movs[hl]dup is on the integer domain so we'l see a domain crossing penalty here(?). But since this is a generic arch/tuning regression the SSE2 code path should be what matters - on the committed testcase I see foo: .LFB572: .cfi_startproc pxor%xmm0, %xmm0 addss (%rdi), %xmm0 addss 4(%rdi), %xmm0 addss 8(%rdi), %xmm0 addss 12(%rdi), %xmm0 ret where it seems that the vectorizer doesn't pick up the reduction pattern. /home/rguenther/src/gcc2/gcc/testsuite/gcc.target/i386/sse2-pr101059.c:20:21: note: vect_is_simple_use: vectype vector(4) float /home/rguenther/src/gcc2/gcc/testsuite/gcc.target/i386/sse2-pr101059.c:20:21: missed: reduc op not supported by target.
[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 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-24 Ever confirmed|0 |1
[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 #1 from rguenther at suse dot de --- On Thu, 23 Sep 2021, dmalcolm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 > > Bug ID: 102471 >Summary: RFE: add support to analyzer testsuite for running > SAMATE/SARD tests (e.g. Juliet Test Suite) >Product: gcc >Version: 12.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: analyzer > Assignee: dmalcolm at gcc dot gnu.org > Reporter: dmalcolm at gcc dot gnu.org > CC: rguenth at gcc dot gnu.org > Target Milestone: --- > > See: > https://www.nist.gov/itl/ssd/software-quality-group/samate > https://samate.nist.gov/SARD/testsuite.php > > The links above have various promising-looking testsuites e.g. > - Juliet Test Suite > - Klocwork test suite > - ITC-Benchmarks > etc > > It would be good to be able to (somehow) automatically run them as part of > regression testing of the analyzer - either by turning them directly into > DejaGnu tests, or by wrapping the suite's own harness in a way that we can > invoke it during "make check". It might be also feasible to think of on-the-side CI runs of external testsuites on buildbots or similar and have results reported on gcc.gnu.org.
