[Bug sanitizer/99190] New: Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190
Bug ID: 99190
Summary: Undefined behaviour in libubsan
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail 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: ---
// gcc -fsanitize=shift -w
// ldd a.out produces
// libubsan.so.1 => /home/vitti/local/gcc-150221-undefined/lib64/libubsan.so.1
// ./a.out produces
// ../../../../gcc-150221/libsanitizer/ubsan/ubsan_value.cpp:77:25: runtime
error: left shift of 0xfffb by 96 places cannot be
represented in type '__int128'
// ubsan_value.cpp:77 -> "return SIntMax(Val) << ExtraBits >> ExtraBits;"
int main (void)
{
1 << -5;
return 0;
}
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #1 from Jakub Jelinek --- It is UB only in C++17 or earlier, so one way to "fix" it is build libubsan with -std=gnu++20. Or the SIntMax(Val) << ExtraBits >> ExtraBits can be replaced by SIntMax(UIntMax(Val) << ExtraBits) >> ExtraBits.
[Bug tree-optimization/99165] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99165 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8a8eee6bdb906788992622715bf97aff984ac989 commit r11-7317-g8a8eee6bdb906788992622715bf97aff984ac989 Author: Richard Biener Date: Mon Feb 22 08:36:55 2021 +0100 tree-optimization/99165 - fix ICE in store-merging w/ non-call EH This adds a missing accumulation to ret. 2021-02-22 Richard Biener PR tree-optimization/99165 * gimple-ssa-store-merging.c (pass_store_merging::process_store): Accumulate changed to ret. * g++.dg/pr99165.C: New testcase.
[Bug tree-optimization/99165] ICE in verify_dominators, at dominance.c:1184 since r11-7205-g95d94b52ea847833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99165 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug fortran/99171] [10/11 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 Richard Biener changed: What|Removed |Added Keywords||build --- Comment #1 from Richard Biener --- Note swapping out parts of the build system isn't tested/supported. Can you quote where the "invalid" -lvtv is present?
[Bug testsuite/99173] [11 Regression] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Summary|new test case |[11 Regression] new test |c-c++-common/attr-retain-5. |case |c added in r11-7284 fails |c-c++-common/attr-retain-5. ||c added in r11-7284 fails Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-22 Priority|P3 |P1 Target Milestone|--- |11.0 --- Comment #3 from Richard Biener --- confirmed.
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-22 Severity|normal |enhancement Version|unknown |11.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/99182] Misleading fixit hint for misspelled Greek letter identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99182 --- Comment #1 from Richard Biener --- I guess it's simply a too similar distance between vt and A
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mark at gcc dot gnu.org, ||vries at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'm not sure if it is a good idea. The indexes are useful when they cover the whole binary or library, when each TU has its own index, then I don't see how it is helpful for the consumer to search each TU's index compared to walking the DIEs. I think .debug_names should be created during linking or post-linking, so ld, dwz or gdb.
[Bug libfortran/99191] New: sanitizer detects undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191 Bug ID: 99191 Summary: sanitizer detects undefined behaviour in libgfortran Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- ! from pr66311.f90 ! must be compiled and run with sanitized libgfortran !../../../gcc-150221/libgfortran/io/write.c:835:7: runtime error: negation of 0x8000 cannot be represented in type '__int128'; cast to an unsigned type to negate this value to itself !../../../gcc-150221/libgfortran/runtime/string.c:199:11: runtime error: negation of 0x8000 cannot be represented in type '__int128'; cast to an unsigned type to negate this value to itself use iso_fortran_env, only : ikinds => integer_kinds integer, parameter :: k = ikinds(size(ikinds)) write(*,*) -huge(0_k)-1 end
[Bug c++/99192] New: A wrong Aggregate initialization for a union with a variant member of non-aggregate class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99192
Bug ID: 99192
Summary: A wrong Aggregate initialization for a union with a
variant member of non-aggregate class type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
struct X { const int a; int b; X(int):a(0){}};
union Y { X x;int k; };
int main(){
Y y{ };
}
Such an example is accepted by GCC(https://godbolt.org/z/hTn8zc) but rejected
by Clang. GCC has a wrong interpretation for this example.
Union `Y` is an aggregate class type as per [dcl.init.aggr#1], So aggregate
initialization is applied to this declaration `Y y{ };`. According to
> If the aggregate is a union and the initializer list is empty, then
>> if any variant member has a default member initializer, that member is
>> initialized from its default member initializer;
>> otherwise, the first member of the union (if any) is copy-initialized from
>> an empty initializer list.
Since there's no default-initializer for a member of Y, hence the second bullet
applies here. That means, the first member will be copy-initialized from an
empty initializer list. However, the class `X` is not an aggregate class type
and it has a user-defined constructor `X(int)`, Hence the following rule will
be applied to initialize `x`, that is:
>Otherwise, if T is a class type, constructors are considered. The applicable
>constructors are enumerated and the best one is chosen through overload
>resolution ([over.match], [over.match.list]). If a narrowing conversion (see
>below) is required to convert any of the arguments, the program is ill-formed.
The only candidate function here is `X(int)` and the corresponding argument
list is empty. So, there's no viable function that exists, Hence the invocation
should be ill-formed here as per:
> If a best viable function exists and is unique, overload resolution succeeds
> and produces it as the result. Otherwise overload resolution fails and the
> invocation is ill-formed.
[Bug libstdc++/99181] char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181
--- Comment #1 from Jakub Jelinek ---
static _GLIBCXX_CONSTEXPR bool
lt(const char_type& __c1, const char_type& __c2) _GLIBCXX_NOEXCEPT
{
// LWG 467.
return (static_cast(__c1)
< static_cast(__c2));
}
static _GLIBCXX17_CONSTEXPR int
compare(const char_type* __s1, const char_type* __s2, size_t __n)
{
if (__n == 0)
return 0;
#if __cplusplus >= 201703L
if (__builtin_constant_p(__n)
&& __constant_char_array_p(__s1, __n)
&& __constant_char_array_p(__s2, __n))
return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
#endif
return __builtin_memcmp(__s1, __s2, __n);
}
Seems the std::char_traits::lt specialization implements LWG467, and so
does std::char_traits::compare when not in constant expression
evaluation,
but the C++17 case above will call __gnu_cxx::char_traits::compare
which doesn't know about LWG 467.
--- libstdc++-v3/include/bits/char_traits.h.jj 2021-01-04 10:26:03.558953845
+0100
+++ libstdc++-v3/include/bits/char_traits.h 2021-02-22 10:42:08.197199781
+0100
@@ -349,7 +349,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (__builtin_constant_p(__n)
&& __constant_char_array_p(__s1, __n)
&& __constant_char_array_p(__s2, __n))
- return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
+ {
+ for (std::size_t __i = 0; __i < __n; ++__i)
+ if (lt(__s1[__i], __s2[__i]))
+ return -1;
+ else if (lt(__s2[__i], __s1[__i]))
+ return 1;
+ return 0;
+ }
#endif
return __builtin_memcmp(__s1, __s2, __n);
}
seems to fix this, but not sure if there isn't a better way.
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22 --- Comment #2 from Martin Liška --- I'll take a look.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I'll handle it.
[Bug c++/99180] ICE with alias template and empty parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99180 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-02-22 Status|UNCONFIRMED |WAITING --- Comment #1 from Martin Liška --- With -std=c++17, it started with r10-5020-g1a291106384cabc7. Is it really a valid test-case?
[Bug demangler/99189] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99189 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-02-22 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Please attach the input.
[Bug demangler/99188] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2021-02-22 --- Comment #2 from Martin Liška --- Please attach the input.
[Bug demangler/99188] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 --- Comment #3 from zhangyuntao --- Created attachment 50230 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50230&action=edit PoC
[Bug demangler/99189] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99189 --- Comment #2 from zhangyuntao --- Created attachment 50231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50231&action=edit PoC
[Bug c/99193] New: Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
Bug ID: 99193
Summary: Bogus "should have been deallocated with 'free' but
was deallocated with 'realloc' [CWE-762]
[-Werror=analyzer-mismatching-deallocation]"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/command.c#L115
This fails to compile with:
gcc -DHAVE_CONFIG_H -I. -I.. -DCAML_NAME_SPACE -I/usr/lib64/ocaml
-I/usr/lib64/ocaml/hivex -I../gnulib/lib -I../gnulib/lib -I../lib -I../lib
-I../common/errnostring -I../common/errnostring -I../common/protocol
-I../common/protocol -I../common/utils -I../common/utils -fanalyzer
-fno-common -Wall -Warith-conversion -Wbad-function-cast -Wcast-align=strict
-Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wduplicated-branches
-Wduplicated-cond -Wextra -Wformat-signedness -Winit-self -Winvalid-pch
-Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes
-Wnested-externs -Wnull-dereference -Wold-style-definition -Wopenmp-simd
-Wpointer-arith -Wstrict-overflow -Wstrict-prototypes -Wsuggest-attribute=cold
-Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-final-methods
-Wsuggest-final-types -Wsync-nand -Wtrampolines -Wuninitialized
-Wunknown-pragmas -Wunused-macros -Wvariadic-macros
-Wvector-operation-performance -Wwrite-strings -Warray-bounds=2
-Wattribute-alias=2 -Wformat-overflow=2 -Wformat=2 -Wformat-truncation=2
-Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wunused-const-variable=2
-Wno-analyzer-double-free -Wno-analyzer-malloc-leak
-Wno-analyzer-null-dereference -Wno-analyzer-use-after-free
-Wno-unused-parameter -Wno-missing-field-initializers -fdiagnostics-show-option
-Wframe-larger-than=6000 -Wstack-usage=1 -Wimplicit-fallthrough=4
-Wformat-truncation=1 -Wformat-overflow=1 -Wno-pragmas -Werror
-I/usr/include/tirpc -I/usr/include/libxml2 -O2 -g -fPIC
-fno-strict-overflow -Wno-strict-overflow -MT guestfsd-command.o -MD -MP -MF
.deps/guestfsd-command.Tpo -c -o guestfsd-command.o `test -f 'command.c' ||
echo './'`command.c
command.c: In function ‘commandrf’:
command.c:136:22: error: ‘argv’ should have been deallocated with ‘free’ but
was deallocated with ‘realloc’ [CWE-762]
[-Werror=analyzer-mismatching-deallocation]
136 | const char **p = realloc (argv, sizeof (char *) * (++i));
| ^~~
‘commandrf’: events 1-4
|
| 125 | argv = malloc (sizeof (char *) * i);
| | ^~~~
| | |
| | (1) allocated here (expects deallocation with ‘free’)
| 126 | if (argv == NULL) {
| | ~
| | |
| | (2) assuming ‘argv’ is non-NULL
| | (3) following ‘false’ branch...
|..
| 130 | argv[0] = (char *) name;
| |
| | |
| | (4) ...to here
|
‘commandrf’: events 5-7
|
| 135 | while ((s = va_arg (args, char *)) != NULL) {
| | ^
| | |
| | (5) following ‘true’ branch
(when ‘s’ is non-NULL)...
| 136 | const char **p = realloc (argv, sizeof (char *) * (++i));
| | ~~~~
| | ||
| | |(7) deallocated with ‘realloc’ here;
allocation at (1) expects deallocation with ‘free’
| | (6) ...to here
|
cc1: all warnings being treated as errors
make[1]: *** [Makefile:3261: guestfsd-command.o] Error 1
This error appears to be bogus.
argv has __attribute__((cleanup)) which will call free(3) on return
paths out of the function, such as realloc failing. If realloc
is successful then the old argv is freed and the new allocation
is assigned to argv.
[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 --- Comment #1 from Richard W.M. Jones --- Created attachment 50232 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50232&action=edit preprocessed source (xz compressed)
[Bug demangler/99189] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99189 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Keywords||ice-on-invalid-code --- Comment #3 from Martin Liška --- Ok, the input is a garbage.
[Bug demangler/99188] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Keywords||ice-on-invalid-code --- Comment #4 from Martin Liška --- Ok, the input is a garbage.
[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 Richard W.M. Jones changed: What|Removed |Added Version|unknown |11.0 --- Comment #2 from Richard W.M. Jones --- Version of GCC: gcc-11.0.0-0.19.fc35.x86_64
[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #3 from Richard W.M. Jones ---
This seems to be the same thing at a different place in the code:
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/df/main.c#L404
CC virt_df-main.o
main.c: In function 'make_display_name':
main.c:404:11: error: 'ret' should have been deallocated with 'free' but was
deallocated with 'realloc' [CWE-762]
[-Werror=analyzer-mismatching-deallocation]
404 | ret = realloc (ret, len + pluses + 1);
| ^~~
'make_display_name': event 1
|
| 378 | make_display_name (struct drv *drvs)
| | ^
| | |
| | (1) entry to 'make_display_name'
|
'make_display_name': event 2
|
| 382 | assert (drvs != NULL);
| | ^~
| | |
| | (2) following 'true' branch (when 'drvs' is non-NULL)...
|
'make_display_name': events 3-4
|
| 385 | if (drvs->next == NULL)
| | ^~ ~
| | | |
| | | (4) following 'false' branch...
| | (3) ...to here
|
'make_display_name': event 5
|
|cc1:
| (5): ...to here
|
'make_display_name': events 6-8
|
| 396 | while (drvs->next != NULL) {
| | ^
| | |
| | (6) following 'true' branch...
| 397 | drvs = drvs->next;
| |
| | |
| | (7) ...to here
|..
| 401 | ret = single_drive_display_name (drvs);
| |
| | |
| | (8) calling 'single_drive_display_name' from
'make_display_name'
|
+--> 'single_drive_display_name': event 9
|
| 322 | single_drive_display_name (struct drv *drvs)
| | ^
| | |
| | (9) entry to 'single_drive_display_name'
|
'single_drive_display_name': event 10
|
| 327 | assert (drvs != NULL);
| | ^~
| | |
| | (10) following 'true' branch (when 'drvs' is non-NULL)...
|
'single_drive_display_name': event 11
|
| 328 | assert (drvs->next == NULL);
| | ^~
| | |
| | (11) ...to here
|
'single_drive_display_name': event 12
|
| 328 | assert (drvs->next == NULL);
| | ^~
| | |
| | (12) following 'true' branch...
|
'single_drive_display_name': events 13-19
|
| 330 | switch (drvs->type) {
| | ^~
| | |
| | (13) ...to here
| | (14) following 'case 1:' branch...
|..
| 342 | case drv_uri:
| |
| | |
| | (15) ...to here
| 343 | name = strdup (drvs->uri.orig_uri);
| 344 | if (name == NULL)
| |~
| ||
| |(16) following 'false' branch (when 'name' is
non-NULL)...
|..
| 349 | p = strrchr (name, '/');
| | ~
| | |
| | (17) ...to here
|..
| 370 | if (!name)
| | ~
| | |
| | (18) following 'false' branch (when 'name' is
non-NULL)...
|..
| 373 | return name;
| | ~~
| | |
| | (19) ...to here
|
<--+
|
'make_display_name': events 20-21
|
| 401 | ret = single_drive_display_name (drvs);
| | ^~~~
| | |
| | (20) returning to 'make_display_name' from
'single_drive_display_name'
|..
| 404 | ret = realloc (ret, len + pluses + 1);
| | ~~~
| | |
| | (21) deallocated with 'realloc' here
|
cc1: all warnings being treated as errors
[Bug ipa/99194] New: [11 Regression] ICE in force_constant_size, at gimplify.c:733 since r11-38-g375a77925c320a27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99194
Bug ID: 99194
Summary: [11 Regression] ICE in force_constant_size, at
gimplify.c:733 since r11-38-g375a77925c320a27
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org,
rguenth at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr99122-3.c -Os -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr99122-3.c:13:20: warning:
‘struct T’ declared inside parameter list will not be visible outside of this
definition or declaration
13 | foo (int n, struct T { char a[n]; } b)
|^
In function ‘foo.constprop’:
cc1: internal compiler error: in force_constant_size, at gimplify.c:733
0x6ac5ac force_constant_size
/home/marxin/Programming/gcc/gcc/gimplify.c:733
0xbac087 gimple_add_tmp_var(tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify.c:771
0xb74c8e create_tmp_var(tree_node*, char const*)
/home/marxin/Programming/gcc/gcc/gimple-expr.c:485
0xbc0fdb create_tmp_from_val
/home/marxin/Programming/gcc/gcc/gimplify.c:564
0xbc0fdb lookup_tmp_var
/home/marxin/Programming/gcc/gcc/gimplify.c:596
0xbc0fdb internal_get_tmp_var
/home/marxin/Programming/gcc/gcc/gimplify.c:635
0xbb973e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:15070
0xbd6a61 gimple_regimplify_operands(gimple*, gimple_stmt_iterator*)
/home/marxin/Programming/gcc/gcc/gimplify-me.c:235
0xef52ba insert_init_stmt
/home/marxin/Programming/gcc/gcc/tree-inline.c:3400
0xf078d6 tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*,
basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:6430
0xa0d0b0 cgraph_node::materialize_clone()
/home/marxin/Programming/gcc/gcc/cgraphclones.c:1131
0x9fa9fd cgraph_node::get_untransformed_body()
/home/marxin/Programming/gcc/gcc/cgraph.c:3903
0xa06dd1 cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1798
0xa0852e expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:1995
0xa0852e symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2359
0xa0852e symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2270
0xa0b167 symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2540
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/99194] [11 Regression] ICE in force_constant_size, at gimplify.c:733 since r11-38-g375a77925c320a27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99194 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Known to fail||11.0 Ever confirmed|0 |1 Last reconfirmed||2021-02-22 Status|UNCONFIRMED |NEW
[Bug ipa/99194] [11 Regression] ICE in force_constant_size, at gimplify.c:733 since r11-38-g375a77925c320a27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99194 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/86487] [8 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 avieira at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from avieira at gcc dot gnu.org --- Closing as it has been backported to 8 and 7 is closed.
[Bug target/99195] New: Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
Bug ID: 99195
Summary: Optimise away vec_concat of 64-bit AdvancedSIMD
operations with zeroes in aarch64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Motivating testcases:
#include
#define ONE(OT,IT,OP,S) \
OT \
foo_##OP##_##S (IT a, IT b) \
{ \
IT zeros = vcreate_##S (0); \
return vcombine_##S (v##OP##_##S (a, b), zeros); \
}
#define FUNC(T,IS,OS,OP,S) ONE (T##x##OS##_t, T##x##IS##_t, OP, S)
#define OPTWO(T,IS,OS,S,OP1,OP2)\
FUNC (T, IS, OS, OP1, S)\
FUNC (T, IS, OS, OP2, S)
#define OPTHREE(T, IS, OS, S, OP1, OP2, OP3)\
FUNC (T, IS, OS, OP1, S)\
OPTWO (T, IS, OS, S, OP2, OP3)
#define OPFOUR(T,IS,OS,S,OP1,OP2,OP3,OP4) \
FUNC (T, IS, OS, OP1, S)\
OPTHREE (T, IS, OS, S, OP2, OP3, OP4)
#define OPFIVE(T,IS,OS,S,OP1,OP2,OP3,OP4, OP5) \
FUNC (T, IS, OS, OP1, S)\
OPFOUR (T, IS, OS, S, OP2, OP3, OP4, OP5)
#define OPSIX(T,IS,OS,S,OP1,OP2,OP3,OP4,OP5,OP6)\
FUNC (T, IS, OS, OP1, S)\
OPFIVE (T, IS, OS, S, OP2, OP3, OP4, OP5, OP6)
OPSIX (int8, 8, 16, s8, add, sub, mul, and, orr, eor)
OPSIX (int16, 4, 8, s16, add, sub, mul, and, orr, eor)
OPSIX (int32, 2, 4, s32, add, sub, mul, and, orr, eor)
OPFIVE (int64, 1, 2, s64, add, sub, and, orr, eor)
OPSIX (uint8, 8, 16, u8, add, sub, mul, and, orr, eor)
OPSIX (uint16, 4, 8, u16, add, sub, mul, and, orr, eor)
OPSIX (uint32, 2, 4, u32, add, sub, mul, and, orr, eor)
OPFIVE (uint64, 1, 2, u64, add, sub, and, orr, eor)
for example generates:
foo_add_s8:
add v0.8b, v0.8b, v1.8b
mov v0.8b, v0.8b
ret
The 64-bit V8QI ADD instruction implicitly zeroes out the top bits of the
128-bit destination so the vec_concat with zeroes can be represented easily.
However we don't have such pattern for all the AdvancedSIMd operations that we
support. Indeed, it would bloat the MD files quite a bit. Can we come up with a
define_subst scheme to auto-generate the patterns to match things like:
(set (reg:V16QI 93 [ ])
(vec_concat:V16QI (plus:V8QI (reg:V8QI 98)
(reg:V8QI 99))
(const_vector:V8QI [
(const_int 0 [0]) repeated x8
])))
?
Then we should be able to just generate:
foo_add_s8:
add v0.8b, v0.8b, v1.8b
ret
etc.
The testcase above shows the problem for some of the simple binary ops, but
there are many more instructions that can benefit from this.
[Bug fortran/99027] Incorrect ubound result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99027 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:700dcc60b5646cc64ae3ba72a79a7542b4902b50 commit r10-9380-g700dcc60b5646cc64ae3ba72a79a7542b4902b50 Author: Tobias Burnus Date: Fri Feb 19 10:42:15 2021 +0100 Fortran: Fix ubound simplifcation [PR99027] gcc/fortran/ChangeLog: PR fortran/99027 * simplify.c (simplify_bound_dim): Honor DIMEN_ELEMENT when using dim=. gcc/testsuite/ChangeLog: PR fortran/99027 * gfortran.dg/ubound_1.f90: New test. (cherry picked from commit f600f271b10d0214b111f2aa52a3d5740477e139)
[Bug c/99196] New: GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196
Bug ID: 99196
Summary: GCC analyzer doesn't know that error (code != 0, ...)
exits the program
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rjones at redhat dot com
Target Milestone: ---
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/tar.c#L108
tar.c: In function 'read_error_file':
tar.c:113:11: error: use of NULL 'str' where non-null expected [CWE-476]
[-Werror=analyzer-null-argument]
113 | len = strlen (str);
| ^~~~
'read_error_file': events 1-7
|
| 109 | if (str == NULL) {
| | ^
| | |
| | (1) following 'true' branch (when 'str' is NULL)...
| 110 | str = strdup ("(no error)");
| | ~~~ ~
| | | |
| | | (3) allocated here
| | (2) ...to here
| 111 | if (str == NULL)
| |~
| ||
| |(4) assuming 'str' is NULL
| |(5) following 'true' branch (when 'str' is NULL)...
| 112 | error (EXIT_FAILURE, errno, "strdup"); /* XXX */
| | ~
| | |
| | (6) ...to here
| 113 | len = strlen (str);
| |
| | |
| | (7) argument 1 ('str') NULL where non-null expected
|
In file included from ../gnulib/lib/string.h:41,
from tar.c:23:
/usr/include/string.h:391:15: note: argument 1 of 'strlen' must be non-null
391 | extern size_t strlen (const char *__s)
| ^~
cc1: all warnings being treated as errors
In the original code if str == NULL, error (EXIT_FAILURE, ...) is
called which exits the program. Therefore strlen (NULL) cannot
be called so the warning is bogus.
https://www.man7.org/linux/man-pages/man3/error.3.html
"If status has a nonzero value, then error() calls exit(3) to
terminate the program using the given value as the exit status."
gcc-11.0.0-0.19.fc35.x86_64
[Bug c/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193
--- Comment #4 from Richard W.M. Jones ---
And another:
https://github.com/libguestfs/libguestfs/blob/f19fd566f6387ce7e4d82409528c9dde374d25e0/daemon/debug.c#L115
debug.c: In function 'debug_help':
debug.c:129:9: error: 'r' should have been deallocated with 'free' but was
deallocated with 'realloc' [CWE-762]
[-Werror=analyzer-mismatching-deallocation]
129 | p = realloc (r, len + 1);/* +1 for the final NUL */
| ^~~~
'debug_help': events 1-4
|
| 120 | r = strdup ("Commands supported:");
| | ^~
| | |
| | (1) allocated here (expects deallocation with 'free')
| 121 | if (!r) {
| | ~
| | |
| | (2) assuming 'r' is non-NULL
| | (3) following 'false' branch (when 'r' is non-NULL)...
|..
| 126 | len = strlen (r);
| | ~~~
| | |
| | (4) ...to here
|
'debug_help': events 5-7
|
| 127 | for (i = 0; cmds[i].cmd != NULL; ++i) {
| | ^
| | |
| | (5) following 'true' branch...
| 128 | len += strlen (cmds[i].cmd) + 1; /* space + new command */
| | ~~~
| | |
| | (6) ...to here
| 129 | p = realloc (r, len + 1);/* +1 for the final NUL */
| |
| | |
| | (7) deallocated with 'realloc' here; allocation at (1)
expects deallocation with 'free'
|
cc1: all warnings being treated as errors
[Bug fortran/99027] Incorrect ubound result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99027 --- Comment #6 from Tobias Burnus --- Now also FIXED for the GCC 10 branch. (In reply to Andrew Burgess from comment #4) > Can confirm that with latest GCC HEAD I am now seeing the results that I > expect. Thanks for the quick fix. :-) You are welcome. Thanks for the report!
[Bug fortran/99183] Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 --- Comment #1 from Ev Drikos --- It turns out that the title isn't very accurate. It's a compile time error! Ev. Drikos
[Bug target/99197] New: Built-ins for packing/unpacking __ibm128 not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99197 Bug ID: 99197 Summary: Built-ins for packing/unpacking __ibm128 not documented Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Target: powerpc*-*-* https://gcc.gnu.org/onlinedocs/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html has the prototypes: double __builtin_unpack_ibm128 (__ibm128, int); __ibm128 __builtin_pack_ibm128 (double, double); But they are undocumented. The simplest fix might be to just point to the next section of the docs and say they behave the same as the corresponding __builtin_xxx_longdouble built-ins.
[Bug fortran/99171] [10/11 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:e9b34037cdd196ab912a7ac3358f8a8d3e307e92 commit r11-7320-ge9b34037cdd196ab912a7ac3358f8a8d3e307e92 Author: Tobias Burnus Date: Mon Feb 22 13:20:26 2021 +0100 Fortran/OpenMP: Fix optional dummy procedures [PR99171] gcc/fortran/ChangeLog: PR fortran/99171 * trans-openmp.c (gfc_omp_is_optional_argument): Regard optional dummy procs as nonoptional as no special treatment is needed. libgomp/ChangeLog: PR fortran/99171 * testsuite/libgomp.fortran/dummy-procs-1.f90: New test.
[Bug c/99198] New: when combinating nested function and __builtin_call_with_static_chain, optimization triggers an internal compiler error (verify_gimple)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99198
Bug ID: 99198
Summary: when combinating nested function and
__builtin_call_with_static_chain, optimization
triggers an internal compiler error (verify_gimple)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhan3299 at purdue dot edu
Target Milestone: ---
Following code is reduced by c-reduce and meaningless, but seems valid as gcc
-O0 accept it.
Under O0, the program can be successfully compiled
(https://godbolt.org/z/zvGxTP); but under O1, it triggers an internal compiler
error (https://godbolt.org/z/xbvrs6). Besides, any version prior version 11.0
has no such problem.
$ cat test.c
int main() {
void f() {}
__builtin_call_with_static_chain(f(), &f);
return 0;
}
$ gcc --version
gcc (Compiler-Explorer-Build) 11.0.0 20210221 (experimental)
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.
$ gcc -O0 test.c # Execution build compiler returned: 0
$ gcc -O1 test.c
: In function 'main':
:1:5: error: static chain with function that doesn't use one
1 | int main() {
| ^~~~
f (); [static-chain: f]
during GIMPLE pass: *warn_unused_result
:1:5: internal compiler error: 'verify_gimple' failed
0x1a31d99 internal_error(char const*, ...)
???:0
0xdc218d verify_gimple_in_seq(gimple*)
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/99194] [11 Regression] ICE in force_constant_size, at gimplify.c:733 since r11-38-g375a77925c320a27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99194 --- Comment #1 from Richard Biener --- Isn't this a dup of PR99122 (the IPA-CP case)?
[Bug demangler/99188] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 --- Comment #5 from zhangyuntao --- “Ok, the input is a garbage.” Do you mean the input is not a crash to cxxfilt? Why does the program crash?
[Bug c/99198] when combinating nested function and __builtin_call_with_static_chain, optimization triggers an internal compiler error (verify_gimple)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99198
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||ice-checking
Last reconfirmed||2021-02-22
--- Comment #1 from Richard Biener ---
So we verify
/* If there is a static chain argument, the call should either be
indirect, or the decl should have DECL_STATIC_CHAIN set. */
if (gimple_call_chain (stmt)
&& fndecl
&& !DECL_STATIC_CHAIN (fndecl))
{
error ("static chain with function that doesn%'t use one");
return true;
}
and when changing the testcase to
int main() {
void f() {}
void (*g)() = f;
__builtin_call_with_static_chain(g(), &f);
return 0;
}
CCP properly clears the static chain when propagating 'f'. Thus folding
of __builtin_call_with_static_chain should properly do the same.
[Bug demangler/99188] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 --- Comment #6 from Martin Liška --- (In reply to zhangyuntao from comment #5) > “Ok, the input is a garbage.” > Do you mean the input is not a crash to cxxfilt? Why does the program crash? It likely makes cxxfilt crashing. I'm just saying it's likely a product of a fuzzer and it's very unlikely to be fixed.
Re: [Bug jit/99126] Compilation ICE trying insert trap
"dmalcolm at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 > > --- Comment #8 from David Malcolm --- > (In reply to CVS Commits from comment #6) >> The master branch has been updated by David Malcolm : >> >> https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707 >> >> commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707 > > Fixed on trunk for gcc 11. Andrea, do you need my to backport this? What GCC > versions are you targeting with your emacs project? We are targetting them all, but to my test I could not trigger this bug on GCC9 so I guess we could backport on GCC10 only?
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #9 from Andrea Corallo --- "dmalcolm at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 > > --- Comment #8 from David Malcolm --- > (In reply to CVS Commits from comment #6) >> The master branch has been updated by David Malcolm : >> >> https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707 >> >> commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707 > > Fixed on trunk for gcc 11. Andrea, do you need my to backport this? What GCC > versions are you targeting with your emacs project? We are targetting them all, but to my test I could not trigger this bug on GCC9 so I guess we could backport on GCC10 only?
[Bug c++/99174] [modules] ICE with recursive inclusion of header-unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99174 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22 Ever confirmed|0 |1
[Bug rtl-optimization/98791] [11 Regression] ICE in paradoxical_subreg_p (in ira) with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791 --- Comment #4 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:4c31a3a6d31b6214ea774d403bf8ab7ebe1ea862 commit r11-7321-g4c31a3a6d31b6214ea774d403bf8ab7ebe1ea862 Author: Andre Vieira Date: Mon Feb 22 13:41:46 2021 + ira: Make sure allocno copies are ordered [PR98791] gcc/ChangeLog: 2021-02-22 Andre Vieira PR rtl-optimization/98791 * ira-conflicts.c (process_regs_for_copy): Don't create allocno copies for unordered modes. gcc/testsuite/ChangeLog: 2021-02-22 Andre Vieira PR rtl-optimization/98791 * gcc.target/aarch64/sve/pr98791.c: New test.
[Bug fortran/99171] [10/11 Regression] Optional procedure call inside Open MP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:08f43c8c98196b2c9b9476aa20b36a3ee629b3a1 commit r10-9381-g08f43c8c98196b2c9b9476aa20b36a3ee629b3a1 Author: Tobias Burnus Date: Mon Feb 22 13:20:26 2021 +0100 Fortran/OpenMP: Fix optional dummy procedures [PR99171] gcc/fortran/ChangeLog: PR fortran/99171 * trans-openmp.c (gfc_omp_is_optional_argument): Regard optional dummy procs as nonoptional as no special treatment is needed. libgomp/ChangeLog: PR fortran/99171 * testsuite/libgomp.fortran/dummy-procs-1.f90: New test. (cherry picked from commit e9b34037cdd196ab912a7ac3358f8a8d3e307e92)
[Bug fortran/99171] [10/11 Regression] Optional procedure call inside OpenMP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 --- Comment #5 from Tobias Burnus --- (In reply to Tobias Burnus from comment #4) > FIXED – both on mainline (GCC 11) and on the GCC 11 branch. ... and GCC 10 (!) branch.
[Bug fortran/99171] [10/11 Regression] Optional procedure call inside OpenMP parallel loop produces Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99171 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Keywords||wrong-code Summary|[10/11 Regression] Optional |[10/11 Regression] Optional |procedure call inside Open |procedure call inside |MP parallel loop produces |OpenMP parallel loop |Segmentation Fault |produces Segmentation Fault Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tobias Burnus --- FIXED – both on mainline (GCC 11) and on the GCC 11 branch. Thanks for the report!
[Bug tree-optimization/99199] New: [9/10/11 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 Bug ID: 99199 Summary: [9/10/11 Regression] Very large boolean expression leads to quite a few return statements Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Created attachment 50233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50233&action=edit C test case The attached test case translated rather strangely with -O3. The instruction sequence is very long, and it generates 42 return instructions, quite a few of them at the end: $ gcc -O3 -S tr.c $ wc -l tr.s 504 tr.s $ grep ret tr.s | wc -l 42 ... L24: movl%r9d, %eax orl %r8d, %eax xorl$1, %eax jmp .L112 .L131: ret .L132: ret .L140: ret .L141: ret .L145: ret .L146: ret .L148: ret .L142: ret .L143: ret .L150: ret .L152: ret .L151: ret .L138: ret .L129: ret .L147: ret .cfi_endproc Seems to have been introduced with gcc 9, gcc 8 is fine.
[Bug tree-optimization/99199] [9/10/11 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 Thomas Koenig changed: What|Removed |Added Version|unknown |11.0 Target Milestone|--- |11.0
[Bug fortran/99138] ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Keywords||ice-on-valid-code --- Comment #2 from Tobias Burnus --- Confirmed – with 'class(*), allocatable :: f(:)' it should be valid (with prior assignment). The problem is in gfc_match_rvalue: 3737 if (sym->ts.type == BT_CLASS && sym->attr.class_ok 3738 && CLASS_DATA (sym)->as) without submodules, we have: sym->ts.u.derived->components->as which is working (and either NULL in the original example or != NULL with my modification). However, with submodules, sym->ts.u.derived->components is NULL, i.e. 'sym->ts.u.derived' (name = "STAR") does not have any scomponents, but it should have two, _data and _vptr!
[Bug libstdc++/99181] char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2021-02-22 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 50234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50234&action=edit gcc11-pr99181.patch Full untested patch.
[Bug c++/99200] New: __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200
Bug ID: 99200
Summary: __PRETTY_FUNCTION__ used as template parameter causes
internal compiler error (segmentation fault)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jbaptistapsilva at yahoo dot com.br
Target Milestone: ---
Created attachment 50235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50235&action=edit
Preprocessor output
Trying to use the macro __PRETTY_FUNCTION__ as a string-literal converted type
parameter (using the new feature of literal classes as non-type template
parameters, and using the technique applied here:
https://ctrpeach.io/posts/cpp20-string-literal-template-parameters/) causes a
segmentation fault on the compiler, which is then posted as an internal
compiler error.
The version, system type and configuration options are:
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.2.0-5ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
gcc version 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04)
Compiler executable checksum: d716f9df9d1b12ebc8fe860554136f35
The entire command line used was this:
g++-10 -std=c++2a -O3 pretty-function-segfault-gcc-10.cpp
The compiler output for the file is:
pretty-function-segfault-gcc-10.cpp: In function ‘consteval const char*
type_name()’:
pretty-function-segfault-gcc-10.cpp:37:49: internal compiler error:
Segmentation fault
37 | return TypeNameConverter<__PRETTY_FUNCTION__>{};
| ^
[Bug c/99134] S390x: pfpo instructions are not used for dfp[128|64|32] to/from long double conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99134 stli at linux dot ibm.com changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from stli at linux dot ibm.com --- I've just restested libdfp with gcc-head: $ git log --oneline 60b99ee3bc0 (HEAD -> master, origin/master, origin/HEAD) Daily bump. ... b6e446cb581 IBM Z: Fix long double <-> DFP conversions a974b8a592e IBM Z: Improve FPRX2 <-> TF conversions Now all the long double <-> _Decimal data-type conversions are using the pfpo instruction. Thanks.
[Bug c++/99200] __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200 --- Comment #1 from JoaoBapt --- I created a Godbolt snippet which also shows that the bug is still there in GCC 11. The entire output (but the .ii) is there on the command line: https://godbolt.org/z/njMM3f
[Bug libstdc++/99181] char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181 --- Comment #3 from Jonathan Wakely --- We're in namespace std here so size_t doesn't need to be qualified, but otherwise the patch is fine.
[Bug tree-optimization/99199] [9/10/11 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 Jakub Jelinek changed: What|Removed |Added CC||glisse at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So many ret insns started with r8-4600-g611a7c7e3799549b0de94c75ca810ba0d450b804 When looking just about number of lines in assembly, there was a rise in number of lines (452 -> 476) already with r8-4395-ge268a77b59cb788637d6db4829f0fd1ddf63f6f2 and then (479 -> 550) in r8-4579-g0cea1d34f781ba9e08ffa82458f0410b398e9c93. Though I don't see how r8-4579 could have changed something when there is no inlining.
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 --- Comment #3 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:c49fcfddaa47f2828fe2af11ae857cd67f53e23f commit r11-7322-gc49fcfddaa47f2828fe2af11ae857cd67f53e23f Author: Nathan Sidwell Date: Mon Feb 22 06:43:32 2021 -0800 c++: cross-header-unit template definitions [PR 99153] A member function can be defined in a different header-file than the one defining the class. In such situations we must unmark the decl as imported. When the entity is a template we failed to unmark the template_decl. Perhaps the duplication of these flags on the template_decl from the underlying decl is an error. I set on the fence about it for a long time during development, but I don't think now is the time to change that (barring catastrophic bugs). PR c++/99153 gcc/cp/ * decl.c (duplicate_decls): Move DECL_MODULE_IMPORT_P propagation to common-path. * module.cc (set_defining_module): Add assert. gcc/testsuite/ * g++.dg/modules/pr99153_a.H: New. * g++.dg/modules/pr99153_b.H: New.
[Bug c++/99153] [11 Regression] ICE: depset::hash::make_dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99153 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Nathan Sidwell --- c49fcfddaa4 2021-02-22 | c++: cross-header-unit template definitions [PR 99153] I have verified that iostream, utility and algorithm can be built
[Bug c++/99201] New: ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201
Bug ID: 99201
Summary: ICE in tsubst_copy, at cp/pt.c:16581
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Testcase (reduced with C-Vise from valid code):
template void test_values_2arg(int, int, F... fun_pack) {
[] {}(fun_pack()...);
}
template auto make_tester(TestF, RefF) {
return [](auto...) {
[](auto... vs) {
if constexpr ([&] { reffun(vs...); })
;
};
};
}
void test() {
auto __trans_tmp_1 = make_tester([] {}, [] {});
test_values_2arg({}, {}, __trans_tmp_1);
}
ice.cpp: In instantiation of 'make_tester,
test():: >:: [with auto:1 = {}]':
ice.cpp:2: required from 'void test_values_2arg(int, int, F ...) [with
= int; F = {make_tester,
test():: >::}]'
ice.cpp:14: required from here
ice.cpp:7: internal compiler error: in tsubst_copy, at cp/pt.c:16581
7 | if constexpr ([&] { reffun(vs...); })
| ^~
0x66f262 tsubst_copy
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:16581
0x804fae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:20719
0x804e6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19497
0x804e6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:20841
0x816cc4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19497
0x816cc4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19107
0x815dec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x815dec tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:13148
0x806acd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:20148
0x816cc4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19497
0x816cc4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:19107
0x817cee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x817cee tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18177
0x818893 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x818893 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18147
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18498
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
0x8177da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18498
0x81f84b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mkretz/src/gcc-simd/gcc/cp/pt.c:18132
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #3 from Martin Liška --- Very interesting issue, the failure is caused by IPA ICF that merges 2 variables with different alignments. I've got a patch candidate.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #2 from gcc-user at riseup dot net --- > Note swapping out parts of the build system isn't tested/supported. This is both a gcc and GNU libtool bug, gcc is passing invalid flags and libtool is silently hiding the fact. I understand that slibtool may be untested in gcc, but since its actually doing the right thing here and has several benefits over GNU libtool (Maintained and readable codebase) it would be very appreciated if this can be fixed. > Can you quote where the "invalid" -lvtv is present? Honestly the gcc build system is confusing for me, but see this comment from the gentoo issue. https://bugs.gentoo.org/767706#c7 Briefly it explained that -lvtv comes from -fvtable-verify=std in a gcc spec file and is propogated to Makefile.in by gcc/Makefile.def.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #3 from Martin Liška --- Interesting, you are searching for UBSAN in libsanitizer. Can you please share details how do you build libubsan with -fsanitize=shift?
[Bug analyzer/99193] Bogus "should have been deallocated with 'free' but was deallocated with 'realloc' [CWE-762] [-Werror=analyzer-mismatching-deallocation]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99193 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Component|c |analyzer --- Comment #5 from Martin Sebor --- Reassigning to analyzer.
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Component|c |analyzer Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Reassigning to analyzer.
[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.5 CC||mpolacek at gcc dot gnu.org Summary|ICE in tsubst_copy, at |[8/9/10/11 Regression] ICE |cp/pt.c:16581 |in tsubst_copy, at ||cp/pt.c:16581 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-22 --- Comment #1 from Marek Polacek --- Started with r273944. The reduced test seems to be invalid.
[Bug c++/99200] __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-02-22 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93383 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Looks like a dup of 93383.
[Bug c++/99200] __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99200
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly reduced:
template
struct A
{
constexpr A (const char (&s)[N]) { for (int i = 0; i < N; i++) v[i] = s[i];
v[N] = 0; }
char v[N + 1];
};
template
struct B
{
constexpr operator const char *() { return s.v; }
};
template
const char *
foo ()
{
return B<__PRETTY_FUNCTION__>{};
}
template
const char *
bar ()
{
return B<__FUNCTION__>{};
}
int
main ()
{
auto a = foo ();
auto b = bar ();
}
[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- If r273943 accepted it, perhaps we need another reduction that will result in no errors with that revision and in that ICE (plus no further errors) with r273944.
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 --- Comment #3 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:d789cf134b7e04ffd90e9512e3e591bd16dc6655 commit r11-7323-gd789cf134b7e04ffd90e9512e3e591bd16dc6655 Author: John David Anglin Date: Mon Feb 22 15:32:34 2021 + Add mi_thunk support for vcalls on hppa. gcc/ChangeLog: PR target/85074 * config/pa/pa.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define as hook_bool_const_tree_hwi_hwi_const_tree_true. (pa_asm_output_mi_thunk): Add support for nonzero vcall_offset.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #3 from Jonathan Wakely --- (In reply to gcc-user from comment #2) > Briefly it explained that -lvtv comes from -fvtable-verify=std in a gcc spec > file and is propogated to Makefile.in by gcc/Makefile.def. The -fvtable-verify=std doesn't come from the spec file, it comes from using --enable-vtable-verify to configure gcc. That adds -fvtable-verify=std and the spec file turns that into -lvtv. I don't know why you want to use --enable-vtable-verify but it's not really maintained as far as I can see.
[Bug c++/99201] [8/9/10/11 Regression] ICE in tsubst_copy, at cp/pt.c:16581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 --- Comment #3 from Matthias Kretz (Vir) --- I'll try to find a better reduction.
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by John David Anglin : https://gcc.gnu.org/g:89b7f2b821e0a158fee586b3d655f9a7d925b9c3 commit r10-9382-g89b7f2b821e0a158fee586b3d655f9a7d925b9c3 Author: John David Anglin Date: Mon Feb 22 15:37:22 2021 + Add mi_thunk support for vcalls on hppa. gcc/ChangeLog: PR target/85074 * config/pa/pa.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define as hook_bool_const_tree_hwi_hwi_const_tree_true. (pa_asm_output_mi_thunk): Add support for nonzero vcall_offset.
[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98718 Nathan Sidwell changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-22
[Bug target/85074] FAIL: g++.dg/torture/pr81812.C (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85074 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from John David Anglin --- Fixed on master and gcc-10.
[Bug c++/99174] [modules] ICE with recursive inclusion of header-unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99174 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:afed55036b65526be006d55f003f670ebeadb223 commit r11-7324-gafed55036b65526be006d55f003f670ebeadb223 Author: Nathan Sidwell Date: Mon Feb 22 07:43:56 2021 -0800 c++: Recursing header imports and other duplicates [PR 99174] The fix for 98741 introduced two issues. (a) recursive header units iced because we tried to read the preprocessor state after having failed to read the config. (b) we could have duplicate imports of named modules in our pending queue, and that would lead to duplicate requests for pathnames, which coupled with the use of a null-pathname to indicate we'd asked could lead to desynchronization with the module mapper. Fixed by adding a 'visited' flag to module state, so we ask exactly once. PR c++/99174 gcc/cp * module.cc (struct module_state): Add visited_p flag. (name_pending_imports): Use it to avoid duplicate requests. (preprocess_module): Don't read preprocessor state if we failed to load a module's config. gcc/testsuite/ * g++.dg/modules/pr99174-1_a.C: New. * g++.dg/modules/pr99174-1_b.C: New. * g++.dg/modules/pr99174-1_c.C: New. * g++.dg/modules/pr99174.H: New.
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #4 from Vittorio Zecca --- To generate a sanitized version of libgfortran I built whole sanitized gcc with the following command: CFLAGS="-g -O0 -fsanitize=undefined -lubsan" LIBS="-lubsan" CXXFLAGS=$CFLAGS ../gcc-150221/configure --prefix=/home/vitti/local/gcc-150221-undefined --enable-languages=c,c++,fortran --disable-multilib --disable-lto --disable-plugin --disable-bootstrap But I remember I had to tweak the build here and there. It is not trivial.
[Bug c++/99174] [modules] ICE with recursive inclusion of header-unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99174 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- afed55036b6 2021-02-22 | c++: Recursing header imports and other duplicates [PR 99174]
[Bug libquadmath/99202] New: Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99202 Bug ID: 99202 Summary: Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- ! from dec_math.f90 ! must be compiled and run ! gfortran compiler needs not be sanitized ! must load sanitized libquadmath.so.0 as in ldd a.out -> libquadmath.so.0 => /home/vitti/local/gcc-150221-undefined/lib64/libquadmath.so.0 ! ../../../gcc-150221/libquadmath/math/rem_pio2q.c:562:26: runtime error: left shift of 4612846647631955497 by 23 places cannot be represented in type 'long int' ! rem_pio2q.c:562 -> "tx [2] = (double)(((ix << 23) | (lx >> 41)) & 0xff);" real(16) :: q_i1, q_oa q_i1 = 34.3774677078493908766176900826395_16 q_oa = cotan (q_i1) end
[Bug libquadmath/99203] New: Undefined behaviour in libquadmath file print_fp.c function __quadmath_printf_fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99203 Bug ID: 99203 Summary: Undefined behaviour in libquadmath file print_fp.c function __quadmath_printf_fp Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- ! from fmt_en.f90 ! must be compiled and run ! gfortran compiler needs not be sanitized ! must load sanitized libquadmath.so.0 ! ldd a.out -> libquadmath.so.0 => /home/vitti/local/gcc-150221-undefined/lib64/libquadmath.so.0 !../../../gcc-150221/libquadmath/printf/printf_fp.c:762:4: runtime error: passing zero to ctz(), which is not a valid argument !../../../gcc-150221/libquadmath/printf/printf_fp.c:762: runtime error: passing zero to ctz(), which is not a valid argument ! printf_fp.c:762 -> "count_trailing_zeros (cnt_l, tmp[0]);" write(*, "(en15.2)") real(-.4,kind=10) write(*, "(en15.2)") real(-.4,kind=16) end
[Bug libfortran/99191] sanitizer detects undefined behaviour in libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99191 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-22 Status|UNCONFIRMED |NEW
[Bug testsuite/99173] [11 Regression] new test case c-c++-common/attr-retain-5.c added in r11-7284 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99173 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The patch might not apply anymore after the AIX changes. In any case, LGTM, please post to gcc-patches though.
[Bug c/99198] when combinating nested function and __builtin_call_with_static_chain, optimization triggers an internal compiler error (verify_gimple)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99198 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 5.5.0, 6.4.0, ||7.2.0, 8.3.0, 9.1.0 CC||msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Bisection points to r217771 (I think that's GCC 5.0) as the first revision to ICE, which is also when __builtin_call_with_static_chain was introduced, so it's not really a regression.
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #4 from zhan3299 at purdue dot edu --- (In reply to Martin Liška from comment #3) > Very interesting issue, the failure is caused by IPA ICF that merges 2 > variables with different alignments. I've got a patch candidate. Hi, just curious because I am also studying the source code of GCC. Is this issue is about sanitizer or optimization?
[Bug fortran/96580] F2018 changes to date_and_time intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-02-22 --- Comment #2 from Dominique d'Humieres --- AFAICT the testing comment 2 works with integer(2) replaced with integer(4) or integer(8), but not with integer(16).
[Bug sanitizer/99190] Undefined behaviour in libubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99190 --- Comment #5 from Vittorio Zecca --- Sorry I meant libubsan, but I am building the whole gcc, g++, and gfortran sanitized version.
[Bug libstdc++/99172] Build failure with slibtool and vtv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99172 --- Comment #4 from gcc-user at riseup dot net --- Thanks for the clarification, regardless -lvtv is then passed to the libtool implementation. With GNU libtool it is silently removed hiding the bug, while slibtool actually passes it to ld which fails when its not valid. Ideally -lvtv should never reach the libtool implementation in this case since its not valid. (It is unfortunate that GNU libtool has hidden issues like this among others for so long...) > I don't know why you want to use --enable-vtable-verify but it's not really > maintained as far as I can see. I was not aware of that, it is default in gentoo. Maybe they should change that? I will add that to the gentoo issue.
[Bug c++/99186] std::tuple compilation error when elements are specializations of template class declared with template < auto E > syntax with E being a enumerator of a enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99186 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #1 from m.cencora at gmail dot com --- This looks like a variation of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93740
[Bug sanitizer/99168] inconsistent behavior on -O0 and -O2 with ASAN on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99168 --- Comment #5 from Martin Liška --- (In reply to zhan3299 from comment #4) > (In reply to Martin Liška from comment #3) > > Very interesting issue, the failure is caused by IPA ICF that merges 2 > > variables with different alignments. I've got a patch candidate. > > Hi, just curious because I am also studying the source code of GCC. > > Is this issue is about sanitizer or optimization? It's bad optimization done by IPA ICF. The issue is gone with -fno-ipa-icf.
[Bug tree-optimization/99199] [9/10/11 Regression] Very large boolean expression leads to quite a few return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199
--- Comment #2 from Jakub Jelinek ---
Until before pro_and_epilogue we have a bb with just code_label, note and
return reg use which has 65 predecessors.
The pro_and_epilogue pass turns that into 65 simple_return jumps.
The ret insns at the end are there since the bbro pass, before that they are at
various spots in the IL and depending on the branch probabilities could even
make sense.
I guess we'd need some simplified crossjumping either during the bbro pass when
going from cfglayout mode into cfgrtl mode, or afterwards (but not too many
passes are left there) that would be able to cross-jump bbs containing those:
(code_label 1552 999 925 128 147 (nil) [1 uses])
(note 925 1552 1389 128 [bb 128] NOTE_INSN_BASIC_BLOCK)
(insn 1389 925 926 128 (use (reg/i:QI 0 ax)) -1
(nil))
(jump_insn 926 1389 927 128 (simple_return) 837 {simple_return_internal}
(nil)
-> simple_return)
[Bug sanitizer/99106] [9/10 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |tree_to_poly_int64, at |tree_to_poly_int64, at |tree.c:3091 |tree.c:3091 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug analyzer/99196] GCC analyzer doesn't know that error (code != 0, ...) exits the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99196 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-02-22 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Thanks for filing this; confirmed. I'm working on a fix.
[Bug fortran/99204] New: ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 Bug ID: 99204 Summary: ICE in fold_read_from_constant_string, at fold-const.c:15441 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 at -O1+ : (gives an error with integer, parameter :: ...) $ cat z1.f90 program p character :: c integer :: i = -12345678 c = 'abc'(i:i) print *, c end $ gfortran-11-20210221 -c z1.f90 -O2 during GIMPLE pass: ccp z1.f90:1:9: 1 | program p | ^ internal compiler error: Segmentation fault 0xc060ef crash_signal ../../gcc/toplev.c:327 0x945af6 poly_int<1u, long>::poly_int(char const&) ../../gcc/poly-int.h:670 0x945af6 fold_read_from_constant_string(tree_node*) ../../gcc/fold-const.c:15441 0x979796 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../gcc/gimple-fold.c:7981 0x97a9d9 fold_const_aggregate_ref(tree_node*) ../../gcc/gimple-fold.c:8136 0x97a9d9 maybe_fold_reference ../../gcc/gimple-fold.c:334 0x980f84 fold_gimple_assign ../../gcc/gimple-fold.c:366 0x980f84 fold_stmt_1 ../../gcc/gimple-fold.c:6077 0xd709b3 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1149 0x148d1b4 dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:309 0xd6fdf5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1283 0xce231b ccp_finalize ../../gcc/tree-ssa-ccp.c:1022 0xce231b do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2579 0xce231b execute ../../gcc/tree-ssa-ccp.c:2622
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Some cases with small numbers : $ cat zz1.f90 program p character :: c = 'c' integer :: i = -1 c = 'abc'(i:i) print *, c end $ cat zz2.f90 program p character :: c = 'c' integer :: i = -123 c = 'abc'(i:i) print *, c end $ gfortran-11-20210221 zz1.f90 -O2 && ./a.out $ gfortran-11-20210221 zz2.f90 -O2 && ./a.out c --- The value at which the switchover from no-ICE to ICE occurs depends on used options, and changes with gfortran versions and environment, e.g. $ cat za.f90 # no-ICE program p character :: c integer :: i = -180 c = 'abc'(i:i) print *, c end $ cat zb.f90 # ICE program p character :: c integer :: i = -190 c = 'abc'(i:i) print *, c end
[Bug fortran/99205] New: [10/11 Regression] Out of memory with undefined character length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205 Bug ID: 99205 Summary: [10/11 Regression] Out of memory with undefined character length Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- This changed between 20190728 and 20190811 : $ cat z1.f90 program p character(l) :: c(2) data c /'a', 'b'/ common c end $ gfortran-11-20210221 -c z1.f90 z1.f90:2:13: 2 |character(l) :: c(2) | 1 Error: Variable 'l' cannot appear in the expression at (1) z1.f90:2:23: 2 |character(l) :: c(2) | 1 Error: 'c' at (1) must have constant character length in this context f951: out of memory allocating 137707388940 bytes after a total of 458752 bytes
[Bug c++/99185] asan initialization-order-fiasco false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99185
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
--- Comment #4 from m.cencora at gmail dot com ---
I think it is just that sanitizer didn't caught up to the C++20 standard where
constexpr was relaxed to allow uninitialized variables.
Constant initialization is applied only when class constructor in constexpr,
and only since C++20 'A' class has constexpr constructor.
Proof, following compiles only since C++20:
struct A {
int value;
constexpr A() = default;
};
[Bug fortran/99206] New: [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 Bug ID: 99206 Summary: [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20200823 and 20201004 : (z1 is invalid, z2 looks valid) $ cat z1.f90 program p character(:), parameter :: a(0) = reshape(['a'], [0]) end $ cat z2.f90 program p character(*), parameter :: a(0) = reshape(['a'], [0]) end $ gfortran-11-20200823 -c z1.f90 z1.f90:2:34: 2 |character(:), parameter :: a(0) = reshape(['a'], [0]) | 1 Error: Entity 'a' at (1) has a deferred type parameter and requires either the POINTER or ALLOCATABLE attribute $ gfortran-11-20210221 -c z1.f90 f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1980 0x66d3e0 add_init_expr_to_sym ../../gcc/fortran/decl.c:1980 0x676f8a variable_decl ../../gcc/fortran/decl.c:2996 0x676f8a gfc_match_data_decl() ../../gcc/fortran/decl.c:6203 0x6db9c3 match_word ../../gcc/fortran/parse.c:65 0x6db9c3 decode_statement ../../gcc/fortran/parse.c:376 0x6dd40c next_free ../../gcc/fortran/parse.c:1316 0x6dd40c next_statement ../../gcc/fortran/parse.c:1548 0x6df7d4 parse_spec ../../gcc/fortran/parse.c:3783 0x6e184c parse_progunit ../../gcc/fortran/parse.c:5896 0x6e2f41 gfc_parse_file() ../../gcc/fortran/parse.c:6437 0x72f98f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-02-22 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- WORKSFORME: % gfc pr99204.f90 % ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. If I compile with -fcheck=all I get % gfc pr99204.f90 -fcheck=all % ./a.out At line 4 of file pr99204.f90 Fortran runtime error: Substring out of bounds: lower bound (-12345678) is less than one
