[Bug c/109979] New: [12 Regression] -Wformat-overflow false positive for %d and non-basic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
Bug ID: 109979
Summary: [12 Regression] -Wformat-overflow false positive for
%d and non-basic expression
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
#include
void f (int *);
void g (void)
{
int e;
char s[4];
f (&e);
sprintf (s, "%d", e);
sprintf (s, "%d", e - 1);
}
I get on my Linux/x86_64 machine with gcc-12 (Debian 12.2.0-14) 12.2.0:
zira:~> gcc-12 -Wformat-overflow -c tst.c
tst.c: In function ‘g’:
tst.c:12:16: warning: ‘%d’ directive writing between 1 and 11 bytes into a
region of size 4 [-Wformat-overflow=]
12 | sprintf (s, "%d", e - 1);
|^~
tst.c:12:15: note: directive argument in the range [-2147483648, 2147483646]
12 | sprintf (s, "%d", e - 1);
| ^~~~
tst.c:12:3: note: ‘sprintf’ output between 2 and 12 bytes into a destination of
size 4
12 | sprintf (s, "%d", e - 1);
| ^~~~
Note that the warning occurs for "e - 1" but not for "e".
This bug was found when compiling GNU MPFR 4.2.0 with "-std=c90 -Werror=format
-m32" (compilation failure for get_d64.c).
[Bug c/109979] [12 Regression] -Wformat-overflow false positive for %d and non-basic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979 --- Comment #1 from Andrew Pinski --- The warning should happen for both ...
[Bug c/109979] -Wformat-overflow false positive for %d and non-basic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Summary|[12 Regression] |-Wformat-overflow false |-Wformat-overflow false |positive for %d and |positive for %d and |non-basic expression |non-basic expression| --- Comment #2 from Andrew Pinski --- The warning happens in GCC 8+ with -O1 and above too ... Really the warning should have happened for the first sprintf too because even though e has no range, it still can overflow the buffer.
[Bug c/109979] -Wformat-overflow false positive for %d and non-basic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979 --- Comment #3 from Andrew Pinski --- Note there is no warning if you use -fwrapv which is what I expected as the range of e-1 becomes the whole range because overflow becomes defined as wrapping
[Bug c/109979] -Wformat-overflow false positive for %d and non-basic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-26 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Confirmed. This is the usual "we don't warn when we know nothing" vs. "we warn if we know a tiny bit" vs. "we have a very good idea" case. From e - 1 we know the range passed does not include INT_MAX so we warn. For 'e' we know nothing so we don't - as Andrew says we probably should diagnose this. If you know the value is in a range that fits s[4] then assert that before the prints.
[Bug sanitizer/109980] New: Bogus Wstringop-overflow and Wstringop-overread warnings when attribute `access` is applied to struct arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109980
Bug ID: 109980
Summary: Bogus Wstringop-overflow and Wstringop-overread
warnings when attribute `access` is applied to struct
arg
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: hacatu5000 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: ---
I'm getting incorrect warnings for some functions using the `access` attribute.
I've managed to reduce the code that produces the error to this:
== access.c ==
typedef struct{
int value, decoy;
} S;
[[gnu::access(read_write, 1)]]
int S_rw(S *self){
return self->value += 1;
}
[[gnu::access(read_only, 1)]]
int S_ro(const S *self){
return self->value;
}
int S_test(S *tmps){
return tmps[1].value && S_rw(tmps + 1) && S_ro(tmps + 1);
}
== compiler options (13.1.1 20230429 x86_64-pc-linux-gnu) ==
gcc -std=c2x -fsanitize=object-size -O1 -c access.c
== output ==
access.c: In function ‘S_test’:
access.c:16:33: warning: ‘S_rw’ accessing 8 bytes in a region of size 4
[-Wstringop-overflow=]
16 | return tmps[1].value && S_rw(tmps + 1) && S_ro(tmps + 1);
| ^~
access.c:6:5: note: in a call to function ‘S_rw’ declared with attribute
‘access (read_write, 1)’
6 | int S_rw(S *self){
| ^~~~
access.c:16:51: warning: ‘S_ro’ reading 8 bytes from a region of size 4
[-Wstringop-overread]
16 | return tmps[1].value && S_rw(tmps + 1) && S_ro(tmps + 1);
| ^~
access.c:2:13: note: source object ‘value’ of size 4
2 | int value, decoy;
| ^
access.c:11:5: note: in a call to function ‘S_ro’ declared with attribute
‘access (read_only, 1)’
11 | int S_ro(const S *self){
|
These incorrect warnings occur regardless of -Wall, -Wextra, and
-fno-strict-aliasing. However, the warnings go away if I remove ANY OF:
- the field `decoy`
- the `access` annotations
- the `tmps[1].value` argument to `&&`
- `-fsanitize=object-size`
- `-O1`
This looks extremely similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689
but I do not get bogus warnings at `-O2`, only with `-fsanitize=object-size`
(an `-O1`). In fact, these warnings GO AWAY when I use both
`-fsanitize=object-size` and `-O2`.
Additionally, I'm seeing invalid -Wstringop-overread, not just
-Wstringop-overflow, although the latter is probably caused by the same CSE bug
that causes these very similar warnings in slightly different circumstances.
[Bug c/109979] -Wformat-overflow false positive for %d and non-basic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979 --- Comment #5 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #1) > The warning should happen for both ... OK (as the documentation says "[...] that might overflow the destination buffer). (In reply to Richard Biener from comment #4) > If you know the value is in a range that fits s[4] then assert that before > the prints. I don't think that an assert() will change anything. With MPFR, the code is in an "else" branch, already with a reduced range. However, this time, I did not use -O2 to enable VRP (I was working on a different issue, but had to use -Werror=format to change the behavior of the configure script); that was my mistake. Then I found the inconsistency between "e" and "e - 1", so I did not look further.
[Bug c++/109981] New: ICE encountered while generating header units in the given sequence in a script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109981 Bug ID: 109981 Summary: ICE encountered while generating header units in the given sequence in a script Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: saifi.khan at nishan dot io Target Milestone: --- Created attachment 55163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55163&action=edit script used to generate header units ENV gcc (GCC) 14.0.0 20230525 (experimental) wrote a Perl script to wrap the generation of the header units. Please see the attached script file. The following is the trace of the processing along with the ICE. --- header-unit 'execution' --- g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header algorithm g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header array g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header charconv g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header chrono g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header concepts g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header expected g++ -std=c++23 -g3 -fmodules-ts -fmodule-only -c -x c++-system-header execution In file included from /opt/gcc/include/c++/14.0.0/pstl/unseq_backend_simd.h:15, from /opt/gcc/include/c++/14.0.0/pstl/memory_impl.h:15, from /opt/gcc/include/c++/14.0.0/pstl/algorithm_impl.h:20, from /opt/gcc/include/c++/14.0.0/pstl/glue_execution_defs.h:50, from /opt/gcc/include/c++/14.0.0/execution:34: /opt/gcc/include/c++/14.0.0/pstl/utils.h: In function ‘typename std::result_of<_Fp()>::type __pstl::__internal::__except_handler(_Fp)’: /opt/gcc/include/c++/14.0.0/pstl/utils.h:35:14: internal compiler error: in install_entity, at cp/module.cc:7630 35 | std::__terminate(); // Good bye according to the standard [algorithms.parallel.exceptions] | ^~~ 0x74db56 trees_in::install_entity(tree_node*) /opt/gcc/src/gcc/cp/module.cc:7630 0xb4c154 trees_in::decl_value() /opt/gcc/src/gcc/cp/module.cc:8144 0xb45b57 trees_in::tree_node(bool) /opt/gcc/src/gcc/cp/module.cc:9344 0xb4dabb module_state::read_cluster(unsigned int) /opt/gcc/src/gcc/cp/module.cc:15022 0xb4e025 module_state::load_section(unsigned int, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:18394 0xb4e0f2 module_state::lazy_load(unsigned int, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:19065 0xb46b7f trees_in::tree_node(bool) /opt/gcc/src/gcc/cp/module.cc:9888 0xb4d829 module_state::read_cluster(unsigned int) /opt/gcc/src/gcc/cp/module.cc:14928 0xb4e025 module_state::load_section(unsigned int, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:18394 0xb4e22c lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*) /opt/gcc/src/gcc/cp/module.cc:19102 0xb609b5 name_lookup::search_namespace_only(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:919 0xb60bc2 name_lookup::search_namespace(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:1005 0xb60bc2 name_lookup::search_namespace(tree_node*) /opt/gcc/src/gcc/cp/name-lookup.cc:998 0xb60cc1 name_lookup::search_qualified(tree_node*, bool) /opt/gcc/src/gcc/cp/name-lookup.cc:1066 0xb65384 qualified_namespace_lookup /opt/gcc/src/gcc/cp/name-lookup.cc:6921 0xb66560 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool) /opt/gcc/src/gcc/cp/name-lookup.cc:6882 0xb77d21 cp_parser_lookup_name /opt/gcc/src/gcc/cp/parser.cc:31291 0xba9be9 cp_parser_class_name /opt/gcc/src/gcc/cp/parser.cc:26003 0xba9edc cp_parser_type_name /opt/gcc/src/gcc/cp/parser.cc:20333 0xbbad17 cp_parser_simple_type_specifier /opt/gcc/src/gcc/cp/parser.cc:20024 Next, i pushed the execution file to the last, then it errors out on 'span' --- header unit 'span' --- In file included from /opt/gcc/include/c++/14.0.0/span:44: /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:140:27: error: ‘__class_or_enum’ was not declared in this scope 140 | concept __adl_end = __class_or_enum> | ^~~ /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:140:65: error: expected primary-expression before ‘>’ token 140 | concept __adl_end = __class_or_enum> | ^~ /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:141:12: error: expected identifier before ‘requires’ 141 | && requires(_Tp& __t) |^~~~ /opt/gcc/include/c++/14.0.0/bits/ranges_base.h:190:30: error: ‘__class_or_enum’ was not declared in this scope 190 | concept __adl_rbegin = __class_or_enum>
[Bug ada/83002] missing finalization of generic package body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83002 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED URL||https://gcc.gnu.org/piperma ||il/gcc-cvs/2023-May/383888. ||html --- Comment #2 from Eric Botcazou --- Fixed on the mainline.
[Bug target/109982] New: csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 Bug ID: 109982 Summary: csmith: x86_64: znver1 issues Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 55164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55164&action=edit C source code The attached C source code does this: $ ../results/bin/gcc -w bug923.c runData/keep/in.11.c: In function ‘func_68’: runData/keep/in.11.c:835:15: note: the ABI for passing parameters with 128-byte alignment has changed in GCC 4.6 $ ./a.out checksum = 4ED89677 $ ../results/bin/gcc -w -march=znver1 bug923.c runData/keep/in.11.c: In function ‘func_68’: runData/keep/in.11.c:835:15: note: the ABI for passing parameters with 128-byte alignment has changed in GCC 4.6 $ ./a.out Segmentation fault (core dumped) $ The bug first seems to appear sometime between snapshot 20221218 (git hash fd69977febf399d1992bbf8d66ae9170e0a4dc9f) and 20221225 (git hash febb58d28bfa4b544ec7ffec2d61f46d25205ff0).
[Bug libstdc++/109976] error: is not a constant expression in std::equal() with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109976 --- Comment #2 from Jonathan Wakely --- (In reply to Ed Catmur from comment #0) > This appears to be caused by bug 109975, but I'm filing separately since it > may be possible to fix in library. Maybe we can skip some of the debug checks during constant evaluation, relying on the compiler to diagnose them anyway.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #20 from Georg-Johann Lay ---
Here is a testcase similar to the one from PR55181, where the first test is for
the sign bit:
unsigned char lfsr32_mpp_sign (unsigned long number)
{
unsigned char b = 0;
if (number & (1UL << 31)) b--;
if (number & (1UL << 29)) b++;
if (number & (1UL << 13)) b++;
return b;
}
unsigned char lfsr32_ppp_sign (unsigned long number)
{
unsigned char b = 0;
if (number & (1UL << 31)) b++;
if (number & (1UL << 29)) b++;
if (number & (1UL << 13)) b++;
return b;
}
What then happens is:
expr.cc::do_store_flag()
expmed.cc::emit_store_flag_force()
expmed.cc::emit_store_flag()
expmed.cc::emit_store_flag_1()
the latter then does:
if (STORE_FLAG_VALUE == 1 || normalizep)
/* If we are supposed to produce a 0/1 value, we want to do
a logical shift from the sign bit to the low-order bit; for
a -1/0 value, we do an arithmetic shift. */
op0 = expand_shift (RSHIFT_EXPR, int_mode, op0,
GET_MODE_BITSIZE (int_mode) - 1,
subtarget, normalizep != -1);
"normalizep" is true because ops->type has a precision of 1, and
STORE_FLAG_VALUE is the default of 1.
Nowhere is there any cost computation or consideration whether extzv could do
the trick.
[Bug ipa/109983] New: [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 Bug ID: 109983 Summary: [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 55165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55165&action=edit packet-rnsap.c.i.xz Originally reported downstream in Gentoo at https://bugs.gentoo.org/907182. Building Wireshark with -fipa-pta ends up hanging when compiling packet-rnsap.c. It's enough to just try to build the reproducer with -O2 -fipa-pta for me (actually, -O1 hangs too): ``` $ gcc-12 -O2 -fipa-pta -c packet-rnsap.c.i [... hangs ...] ``` gcc 11.3.1 20230518 doesn't hang, while 12.3.1 20230519 / 13.1.1 20230520 / 14.0.0 20230521 do.
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 --- Comment #1 from Sam James --- I let perf spin for a while and got this w/ 13: ``` $ perf record gcc-13 -O2 -fipa-pta -c packet-rnsap.c.i [^C'd after ~2 minutes] $ perf report 43.18% cc1 cc1 [.] bitmap_ior_into 40.43% cc1 cc1 [.] bitmap_bit_p 9.65% cc1 cc1 [.] bitmap_set_bit 2.87% cc1 cc1 [.] solve_graph 0.98% cc1 cc1 [.] solution_set_expand 0.80% cc1 cc1 [.] add_graph_edge 0.39% cc1 cc1 [.] find 0.04% cc1 cc1 [.] symbol_table::decl_assembler_name_hash 0.04% cc1 libc.so.6[.] malloc 0.03% cc1 cc1 [.] ggc_set_mark 0.03% cc1 cc1 [.] verify_ssa 0.03% cc1 cc1 [.] gt_ggc_mx_lang_tree_node 0.03% cc1 cc1 [.] walk_gimple_op 0.03% cc1 cc1 [.] walk_tree_1 0.03% cc1 cc1 [.] base_pool_allocator::allocate 0.03% cc1 cc1 [.] solve_constraints 0.02% cc1 cc1 [.] bitmap_list_insert_element_after 0.02% cc1 cc1 [.] verify_gimple_call 0.02% cc1 libc.so.6[.] cfree 0.02% cc1 cc1 [.] ggc_internal_alloc 0.02% cc1 cc1 [.] verify_gimple_in_cfg 0.02% cc1 cc1 [.] equiv_class_lookup_or_add 0.02% cc1 cc1 [.] verify_gimple_stmt 0.02% cc1 [unknown][k] 0x89000b90 0.02% cc1 cc1 [.] do_per_function 0.01% cc1 cc1 [.] hash_table, false, xcallocator>::verify 0.01% cc1 cc1 [.] contains_struct_check 0.01% cc1 cc1 [.] hash_table, align_flags> >::hash_entry, false, xcallocator>::verify 0.01% cc1 cc1 [.] free_dominance_info 0.01% cc1 cc1 [.] operands_scanner::get_expr_operands 0.01% cc1 cc1 [.] verify_expr_location_1 0.01% cc1 cc1 [.] _cpp_lex_direct 0.01% cc1 cc1 [.] verify_location 0.01% cc1 cc1 [.] (anonymous namespace)::dom_info::calc_dfs_tree_nonrec 0.01% cc1 cc1 [.] (anonymous namespace)::dom_info::calc_idoms [...] ```
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 Sam James changed: What|Removed |Added Keywords||compile-time-hog --- Comment #2 from Sam James --- Note that compilation (even with checking off) is kind of slow even without -fipa-pta, but of course it doesn't hang then.
[Bug target/109984] New: FAIL: insn-modes.h: No such file or directory (x86_64-apple-darwin22.4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109984 Bug ID: 109984 Summary: FAIL: insn-modes.h: No such file or directory (x86_64-apple-darwin22.4.0) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc-zm31 at proton dot me Target Milestone: --- When attempting to build GCC with an experimental language frontend, I encounter the following error: In file included from ../../gcc-src/gcc/rinto/rin-system.hpp:30, from ../../gcc-src/gcc/rinto/frontend/backend.hpp:4, from ../../gcc-src/gcc/rinto/frontend/diagnostic.hpp:37, from ../../gcc-src/gcc/rinto/frontend/diagnostic.cc:33: ../../gcc-src/gcc/coretypes.h:458:10: fatal error: insn-modes.h: No such file or directory 458 | #include "insn-modes.h" This only seems to be an issue when passing the -j flag to make. When I otherwise run 'make' on a single processor (without -j), the project compiles. I suspect there might be some oversight on my part, though it could be an issue with the order in which GCC generates header files. The project is configured as follows: ../gcc-src/configure --prefix=/Users/mz/Desktop/gcc-build/../gcc-install --enable-languages=c,c++,rinto --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --disable-nls --enable-checking=release --with-gcc-major-version-only --with-system-zlib And the make command: make -j$(getconf _NPROCESSORS_ONLN) where 'getconf _NPROCESSORS_ONLN; yields 16. Target: x86_64-apple-darwin22.4.0 (though the problem persists on my Ubuntu 22 machine as well). SOURCE-A: https://github.com/rintolang/rinto/tree/main/src/gcc SOURCE-B: https://github.com/rintolang/rinto/tree/main/src/frontend The contents of SOURCE-A are placed in [GCC-ROOT]/gcc/rinto and SOURCE-B in [GCC-ROOT]/gcc/rinto/frontend.
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Paul Thomas changed:
What|Removed |Added
Blocks||87477
--- Comment #8 from Paul Thomas ---
I have flagged that this PR blocks PR87477.
Guarding ref->u.ar.as is good practice. However, it turns out that the
associate name symbol has a perfectly good array_spec. This version "double
fixes" the PR and is somewhat more satisfactory.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 83e45f1b693..9863cdc1583 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5640,7 +5640,12 @@ gfc_expression_rank (gfc_expr *e)
if (ref->type != REF_ARRAY)
continue;
- if (ref->u.ar.type == AR_FULL)
+ if (ref->u.ar.as == NULL
+ && e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->as)
+ ref->u.ar.as = e->symtree->n.sym->as;
+
+ if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
{
rank = ref->u.ar.as->rank;
break;
Gratifyingly, this does the right thing:
implicit none
type tlap
real,allocatable :: z(:)
end type tlap
type(tlap) :: y_in
real :: x_out(3) =[0.0,0.0,0.0]
integer :: pid = 1
y_in%z = [1.0,-2.0,3.0]
call foo(y_in, x_out)
print *, x_out
call foo(y_in, x_out)
print *, x_out
contains
subroutine foo(y, x)
type(tlap) :: y
real :: x(:)
associate(z=>y%z)
if (getpid() == 1) then
where ( z < 0.0 ) x(:) = z(:)
else
where ( z > 0.0 ) x(:) = z(:)
endif
end associate
end subroutine foo
integer function getpid()
getpid = pid
pid = pid + 1
end function getpid
end
Cheers
Paul
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
[Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 --- Comment #1 from Uroš Bizjak --- Also fails with "-mtune=znver1 -mavx": Program received signal SIGSEGV, Segmentation fault. 0x004048ef in func_21 (p_22=0x41b330 , p_23=0, p_24=8) at runData/keep/in.11.c:597 597 in runData/keep/in.11.c (gdb) disass $pc-10, $pc+10 Dump of assembler code from 0x4048e5 to 0x4048f9: 0x004048e5 : mov(%rax),%rdx 0x004048e8 : mov-0x1378(%rbp),%rax => 0x004048ef : vmovdqa (%rdx),%ymm0 0x004048f3 : vmovdqa %ymm0,(%rax) 0x004048f7 : vmovdqa 0x20(%rdx),%ymm0 End of assembler dump. (gdb) p/x $rdx $3 = 0x41a824 Unaligned access.
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 --- Comment #2 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #1) > (gdb) p/x $rdx > $3 = 0x41a824 > > Unaligned access. Actually, just a garbage value.
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 --- Comment #9 from Paul Thomas --- By the way, the patch regtests OK Do you want to do the honours or shall I? I think that this rates as an 'obvious' fix. Paul
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #10 from Mikael Morin ---
(In reply to Paul Thomas from comment #8)
> I have flagged that this PR blocks PR87477.
>
> Guarding ref->u.ar.as is good practice. However, it turns out that the
> associate name symbol has a perfectly good array_spec. This version "double
> fixes" the PR and is somewhat more satisfactory.
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 83e45f1b693..9863cdc1583 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -5640,7 +5640,12 @@ gfc_expression_rank (gfc_expr *e)
>if (ref->type != REF_ARRAY)
> continue;
>
> - if (ref->u.ar.type == AR_FULL)
> + if (ref->u.ar.as == NULL
> + && e->expr_type == EXPR_VARIABLE
> + && e->symtree->n.sym->as)
> + ref->u.ar.as = e->symtree->n.sym->as;
> +
> + if (ref->u.ar.type == AR_FULL && ref->u.ar.as)
> {
> rank = ref->u.ar.as->rank;
> break;
>
Mmh, in a sense it also "double breaks" it. For example, with
associate(z=>array(1)%ar(2,3)%array(:,:,:)), I expect to get the wrong as in
ref->u.ar.as for the last two array references.
You probably want to copy what's done in find_array_spec or directly call it?
My opinion remains that calling eval_intrinsic at parsing time (as it appears
we do from the stack trace) is fundamentally too early. It doesn't make sure
that everything is properly set up, and that all the rules of the standard are
respected. We wouldn't have this problem if the call to eval_intrinsic was
deferred to the resolution time.
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #3 from Sergei Trofimovich --- Quoting `man gcc`: -fipa-pta Perform interprocedural pointer analysis and interprocedural modification and reference analysis. This option can cause excessive memory and compile-time usage on large compilation units. It is not enabled by default at any optimization level. Chances are `gcc` succeeds in a longer time: O(minutes). For me it finishes in 3 minutes on gcc-14. Enabled extra checkers (verify_*) probably make it slower.
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 --- Comment #4 from Sam James --- I know what the option does, but: 1. It's substantially slower in 12/13/14, with or without checking. If that's expected, that's fine, but someone has to say if it is. 2. With default checking (=release) on 12.2.1 20230428, it's taken over 5 minutes. 3. Even lots of checking (yes,rtl,extra) on 11, it takes about 10 seconds.
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 --- Comment #5 from Sergei Trofimovich --- > For me it finishes in 3 minutes on gcc-14. I'll take it back. It does not finish for me in 10 minutes on gcc-14. Don't know where I picked the number.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #21 from Georg-Johann Lay ---
One more test:
unsigned char lfsr32_mpp_ge0 (unsigned long number)
{
unsigned char b = 0;
if (number >= 0) b--;
if (number & (1UL << 29)) b++;
if (number & (1UL << 13)) b++;
return b;
}
with -Os -mmcu=atmega128 -dp it generates:
lfsr32_ppp_ge0:
push r16 ; 85 [c=4 l=1] pushqi1/0
push r17 ; 86 [c=4 l=1] pushqi1/0
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
movw r16,r22 ; 93 [c=4 l=1] *movhi/0
movw r18,r24 ; 94 [c=4 l=1] *movhi/0
movw r22,r18 ; 82 [c=4 l=2] *movsi/0
movw r20,r16
clr r20 ; 83 [c=16 l=4] *andsi3/1
clr r21
clr r22
andi r23,32
ldi r24,lo8(1) ; 68 [c=4 l=1] movqi_insn/1
sbrc r17,5 ; 84 [c=28 l=2] *sbrx_branchsi
rjmp .L18
or r20,r21 ; 75 [c=16 l=3] *cmpsi/0
or r20,r22
or r20,r23
breq .L19; 77 [c=12 l=1] *branch
ldi r24,0; 73 [c=4 l=1] movqi_insn/0
.L19:
neg r24 ; 72 [c=4 l=1] *negqi2
.L17:
/* epilogue start */
pop r17 ; 89 [c=4 l=1] popqi
pop r16 ; 90 [c=4 l=1] popqi
ret ; 91 [c=0 l=1] return_from_epilogue
.L18:
or r20,r21 ; 69 [c=16 l=3] *cmpsi/0
or r20,r22
or r20,r23
brne .L17; 71 [c=12 l=1] *branch
ldi r24,0; 67 [c=4 l=1] movqi_insn/0
rjmp .L17; 95 [c=4 l=1] jump
so it does arithmetic on 32-bit variables (one AND and two COMPAREs) in 28
instructions, use more stack and high register pressure. An optimal code would
require just 8 instructions and additional register pressure of just 1 byte for
the output:
lfsr32_mpp_ge0:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
clr R26 ;; b lives in R26, number lives in R25:R22.
sbrs R25, 7 ;; Skip next if number.31 = 1
dec R26
sbrc R25, 5 ;; Skip next if number.29 = 0
inc R26
sbrc R23, 5 ;; Skip next if number.13 = 0
inc R26
mov R24, r26
/* epilogue start */
ret
[Bug c++/109985] New: __builtin_prefetch ignored by GCC 12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985 Bug ID: 109985 Summary: __builtin_prefetch ignored by GCC 12/13 Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pdimov at gmail dot com Target Milestone: --- We are investigating a Boost.Unordered performance regression with GCC 12, on the following benchmark: https://github.com/boostorg/boost_unordered_benchmarks/blob/4c717baac1bff8d3e51cb8485b72bbb63d533265/scattered_lookup.cpp and it looks like the reason is that GCC 12 (and 13) ignore a call to `__builtin_prefetch`. While GCC 11 generates this: ``` .L108: mov r8, r12 movdqa xmm0, xmm1 sal r8, 4 lea r14, [r10+r8] pcmpeqb xmm0, XMMWORD PTR [r14] pmovmskbedx, xmm0 and edx, 32767 je .L104 sub r8, r12 sal r8, 4 add r8, QWORD PTR [rbx+32] prefetcht0 [r8] .L106: xor r15d, r15d rep bsf r15d, edx movsx r15, r15d sal r15, 4 add r15, r8 cmp rsi, QWORD PTR [r15] jne .L144 add r9, QWORD PTR [r15+8] mov rax, rdi cmp r11, rdi jne .L145 ``` (https://godbolt.org/z/d663fdM16 - prefetcht0 [r8] right before L106) GCC 12 generates this in the same function: ``` .L108: mov r8, r10 movdqa xmm0, xmm1 sal r8, 4 lea r9, [rbp+0+r8] pcmpeqb xmm0, XMMWORD PTR [r9] pmovmskbedx, xmm0 and edx, 32767 je .L104 mov rdi, QWORD PTR [rsp+16] sub r8, r10 mov QWORD PTR [rsp+24], rax sal r8, 4 mov rdi, QWORD PTR [rdi+32] mov QWORD PTR [rsp+8], rdi mov rax, rdi .L106: xor edi, edi rep bsf edi, edx movsx rdi, edi sal rdi, 4 add rdi, r8 add rdi, rax cmp r11, QWORD PTR [rdi] jne .L143 add rsi, 8 add rbx, QWORD PTR [rdi+8] cmp r12, rsi jne .L109 ``` (https://godbolt.org/z/T7csq7TPz - no prefetcht0 instruction before L106) Simplifying this code unfortunately leads to the prefetcht0 being generated.
[Bug middle-end/109986] New: missing fold (~a | b) ^ a => ~(a & b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
Bug ID: 109986
Summary: missing fold (~a | b) ^ a => ~(a & b)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
int foo(int a, int b)
{
return (~a | b) ^ a;
}
This can be optimized to `return ~(a | b);`. This transformation is done by
LLVM, but not by GCC.
[Bug middle-end/109986] missing fold (~a | b) ^ a => ~(a & b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
--- Comment #1 from Ivan Sorokin ---
(In reply to Ivan Sorokin from comment #0)
> int foo(int a, int b)
> {
> return (~a | b) ^ a;
> }
>
> This can be optimized to `return ~(a | b);`. This transformation is done by
> LLVM, but not by GCC.
Correction: it can be optimized to `return ~(a & b);`.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #41 from Alexander Klepikov --- > > It looks like with optimization enabled it converts bitwise AND to right > > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be > > optimized to 'tst'. And SH2E has libcall instead of dynamic shift and libcll > > cannot be converted. It seems that very first optimization spoils things. > > > > But when we have numerous 'shar' instructions, optimization joins the game > > again and converts them to 'tst'. > > Yes, something like this is what I remember happening there. I'll try to > look into the issue with your test cases and see if it's possible to add > some patterns to catch those. Thank you! I have an idea. If it's impossible to defer initial optimization, maybe it's possible to emit some intermediate insn and catch it and optimize later? > BTW, have you tried it on a more recent GCC? There have also been some > optimizations in the middle-end (a bit more backend independent) for this > kind of thing. I tried 13.1 about week or two ago with the same result. > Have you tried to use whole program optimization via -flto and > -ffunction-sections? It should be able to strip out all unnecessary library > functions. Thank you for advice, I'll take a try.
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #13 from Pascal Cuoq --- @Martin I completely agree with comment 12, however about the last paragraph, I would like to point out that for purposes of memcpy'ing to or from such a struct with initialized FAM, it is enough to recommend that programmers use the simple formula “offsetof(struct foo, t) + n * sizeof(char)” (or “offsetof(struct foo, t[n])”. The part that is not copied is the part that they did not intend to use when they chose the initializer of the FAM, and that they cannot portably use because of the padding that may or may not exist for a different target architecture. So since: First, GCC currently does not always reserve enough room to allow “memcpy(…, …, sizeof(struct foo) + n * sizeof(char))”, and second, using the time-proven formula as argument of malloc technically does not always allocate enough space to make it valid to access p->t[n-1] according to the strict interpretation of the words “it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed”, we might as well start recommending that C programmers use “offsetof(struct foo, t) + n * sizeof(char)” as argument of memcpy, and either clarify the meaning of the words “it behaves as if…” in the C standard or prepare for a very unpleasant discussion when we have to tell them the formula they have to use as argument of malloc.
[Bug target/109987] New: ICE in in rs6000_emit_le_vsx_store on ppc64le with -Ofast -mno-power8-vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987 Bug ID: 109987 Summary: ICE in in rs6000_emit_le_vsx_store on ppc64le with -Ofast -mno-power8-vector Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: ppc64le-linux-gnu With a cross compiler (revision r14-1248-gd156c605420023) configured with: /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/configure --enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap --disable-libsanitizer --disable-multilib --enable-checking=release --prefix=/home/worker/cross --target=ppc64le-linux-gnu --with-as=/usr/bin/powerpc64le-suse-linux-as and our existing testcase gcc/testsuite/gcc.target/powerpc/pr102347.c, running it as ~/cross/bin/ppc64le-linux-gnu-gcc /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr102347.c -Ofast -mno-power8-vector Results in ICE: during RTL pass: split2 /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr102347.c: In function ‘main’: /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr102347.c:15:1: internal compiler error: in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.cc:10547 15 | } | ^ 0x63d7f7 rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode) /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.cc:10547 0x1293d37 gen_movv16qi(rtx_def*, rtx_def*) /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/vector.md:161 0x8938b7 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*) const /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.h:407 0x8938b7 emit_move_ccmode /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/expr.cc:4043 0x8938b7 emit_move_insn_1(rtx_def*, rtx_def*) /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/expr.cc:4188 0x893c9d emit_move_insn(rtx_def*, rtx_def*) /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/expr.cc:4339 0x12c925b gen_split_707(rtx_insn*, rtx_def**) /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/mma.md:498 0x136dcda split_14 /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/mma.md:494 0x136dcda split_18 /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.md:471 0x861170 try_split(rtx_def*, rtx_insn*, int) /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/emit-rtl.cc:3804 0xb5af71 split_insn /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.cc:3385 0xb60221 split_all_insns() /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.cc:3489 0xb60308 execute /home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.cc:4413
[Bug target/109973] [13/14 Regression] Wrong code for AVX2 since 13.1 by combining VPAND and VPTEST since r13-2006-ga56c1641e9d25e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
--- Comment #4 from Benji Smith ---
Just as follow-up, I also tested the same code with
_mm_and_si128/_mm_testc_si128 on SSE4.1, and the same issue repros (via `gcc
-O1 -msse4.1`):
#include
int do_stuff(__m128i Y0, __m128i Y1, __m128i X2) {
__m128i And01 = _mm_and_si128(Y0, Y1);
int TestResult = _mm_testc_si128(And01, And01);
return TestResult;
}
[Bug c++/109988] New: -iwithprefix doesn't add folder to end of search list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988 Bug ID: 109988 Summary: -iwithprefix doesn't add folder to end of search list Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ivan.lazaric.gcc at gmail dot com Target Milestone: --- ``` echo | g++ -iprefix "./" -iwithprefix "." -E -v - ``` Snippet of output: ``` #include <...> search starts here: ./. /usr/lib/gcc/x86_64-linux-gnu/11/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include End of search list. ``` Issue is that "./." is at the front of the list, should be at bottom. Snippet of `man g++`: ``` -iprefix prefix Specify prefix as the prefix for subsequent -iwithprefix options. If the prefix represents a directory, you should include the final /. -iwithprefix dir -iwithprefixbefore dir Append dir to the prefix specified previously with -iprefix, and add the resulting directory to the include search path. -iwithprefixbefore puts it in the same place -I would; -iwithprefix puts it where -idirafter would. ``` ^ implying `-iwithprefix` should behave like `-idirafter` `echo | g++ -idirafter "./." -E -v -`: ``` #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/11/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include ./. End of search list. ``` Related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34502
[Bug middle-end/109840] [14 Regression] internal compiler error: in expand_fn_using_insn, at internal-fn.cc:153 when building graphite2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- Many thanks to Sam for confirming this is now fixed on aarch64.
[Bug c++/109988] -iwithprefix doesn't add folder to end of search list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988 --- Comment #1 from Ivan Lazaric --- In `gcc/c-family/c-opts.cc`: ``` case OPT_iwithprefix: add_prefixed_path (arg, INC_SYSTEM); break; ``` Should `INC_SYSTEM` actually be `INC_AFTER` ?
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #10 from Xi Ruoyao --- Frankly I've seen too much "slowing down everyone's system just for some debugging/profiling/whatever tools" thing. So I'd say a clear "no". You may argue 1% performance degradation is acceptable, but the change would be a bad start to justify other changes and at last we'll accumulate a 9.5% degradation with 10 such changes one day. If DWARF unwinding does not work properly, try to fix it or revise the DWARF specification, instead of making every system slower.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #11 from Jakub Jelinek --- DWARF unwinding works properly, just in Linux kernel they decided they don't want it in the kernel (I think they had some non-perfect implementation in the past and it got removed).
[Bug tree-optimization/109989] New: RISC-V: Missing sign extension with int to float conversion with 64bit soft floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989
Bug ID: 109989
Summary: RISC-V: Missing sign extension with int to float
conversion with 64bit soft floats
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: joseph.faulls at imgtec dot com
Target Milestone: ---
Created attachment 55166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55166&action=edit
Preprocessed test
Hi,
This bug was discovered when running test
gcc.target/riscv/promote-type-for-libcall.c on O1 for march rv64imac.
There are a few moving parts to this, and I haven't been able to track down
where the bug lies due to not being at all familiar with gcc. But I've managed
to reduce the test to the following criteria:
Compilation flags:
-march=rv64imac -mabi=lp64 -O1 -ftree-slp-vectorize -funroll-loops
march can be any 64bit without f/d extension.
Removal of any of the other flags (with the given test case) will not cause the
bug.
I have confirmed the only difference between 12.1 and 13.1 is the missing sign
extension before the call to __floatsisf
Inlining the test file here for added comments:
#include
#include
volatile float f[2];
int x[2] ;
int main() {
int i;
x[0] = -1;
x[1] = 2; // Removal of this line avoids the bug
for (i=0;i<1;++i){
f[i] = x[i]; // Any attempt to printf x[i] here avoids the bug
}
if (f[0] != -1.0f) {
abort();
}
return 0;
}
Thanks!
[Bug rtl-optimization/60749] combine is overly cautious when operating on volatile memory references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749 Siarhei Volkau changed: What|Removed |Added CC||lis8215 at gmail dot com --- Comment #2 from Siarhei Volkau --- Created attachment 55167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55167&action=edit allow combine ld/st of volatile mem with any_extend op Is anyone bothering on that? I'm, as embedded engineer, sadly looking on that long standing issue. I can propose a quick patch which enables combining volatile mem ld/st with any_extend for most cases. And it seems, like platform specific test results remain the same with it (arm/aarch64/mips were tested). Post it in hope it can help for anyone who needs it.
[Bug middle-end/109990] New: [12 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 Bug ID: 109990 Summary: [12 Regression] Bogus -Wuse-after-free warning after realloc Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 55168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55168&action=edit test case bar.c Compiling the attached file produces a warning that is not justified: $ gcc -Wall -O2 -S bar.c bar.c: In function ‘read_alias_file’: bar.c:122:52: warning: pointer may be used after ‘realloc’ [-Wuse-after-free] 122 | map[i].alias += new_pool - string_space; | ~^~ bar.c:114:45: note: call to ‘realloc’ here 114 | char *new_pool = (char *) realloc (string_space, new_size); | ^~~~ The warning is not justified because only the pointer 'string_space' is used here; it is not being dereferenced. Seen with gcc 12.3.0 and 13.1.0.
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #1 from Andrew Pinski ---
```
char *new_pool = (char *) realloc (string_space, new_size);
if (new_pool == ((void *)0))
goto out;
if (__builtin_expect (string_space != new_pool, 0))
{
size_t i;
for (i = 0; i < nmap; i++)
{
map[i].alias += new_pool - string_space;
map[i].value += new_pool - string_space;
}
}
string_space = new_pool;
```
Hmmm
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104215 --- Comment #2 from Andrew Pinski --- See also the discussion starting at bug 104215 comment #2.
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> ```
>
> char *new_pool = (char *) realloc (string_space, new_size);
> if (new_pool == ((void *)0))
> goto out;
> if (__builtin_expect (string_space != new_pool, 0))
> {
> size_t i;
> for (i = 0; i < nmap; i++)
> {
> map[i].alias += new_pool - string_space;
> map[i].value += new_pool - string_space;
> }
> }
> string_space = new_pool;
> ```
>
> Hmmm
Also I think `new_pool - string_space` is undefined really. That is
subtracting two unrelated arrays is undefined. You can only compare equality on
them.
[Bug sanitizer/109991] New: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Bug ID: 109991
Summary: stack-use-after-scope
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: igkper 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: ---
Hi,
I believe the below code should result in sanitizer complaining about
stack-use-after-scope, but it does not. I've noted that clang catches this but
not gcc. I've annotated where I've noted it seems to depend on whether or not
constexpr is used. See https://godbolt.org/z/Y3YKcfGda.
using T = int;
struct Wrap
{
T const& v;
// Shouldn't extend lifetime of temporary
constexpr Wrap(T const& in) : v{in} {}
};
struct BadWrapUse final
{
T i{};
constexpr BadWrapUse() // issue not caught with constexpr
// BadWrapUse() // issue caught without constexpr
{
Wrap w{T{}}; // temporary T's lifetime ends after this expression
i = w.v; // This should lead to stack-use-after-scope.
}
};
int main()
{
BadWrapUse c;
}
[Bug c++/109991] stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Component|sanitizer |c++
Last reconfirmed||2023-05-26
Ever confirmed|0 |1
Blocks||55004
--- Comment #1 from Andrew Pinski ---
That is because with constexpr, the code should have been rejected ...
Take this C++20 GCC accepts it (incorrectly) but clang rejects it:
```
using T = int;
struct Wrap
{
T const& v;
constexpr Wrap(T const& in) : v{in} {}
};
struct BadWrapUse final
{
T i{};
consteval BadWrapUse()
{
Wrap w{T{}}; // temporary T's lifetime ends after this expression
i = w.v; // This should lead to stack-use-after-scope.
}
};
int main()
{
BadWrapUse c;
}
```
Note there might be a dup of it somewhere.
Basically in your original example, GCC is doing constexpr evulation but that
is not valid for constant expression evulation ...
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues
[Bug c++/109991] stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 98675. *** This bug has been marked as a duplicate of bug 98675 ***
[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98675 Andrew Pinski changed: What|Removed |Added CC||igkper at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 109991 has been marked as a duplicate of this bug. ***
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 109991, which changed state. Bug 109991 Summary: stack-use-after-scope https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/109986] missing fold (~a | b) ^ a => ~(a & b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed||2023-05-26
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
GCC does handle:
int f0(int a, int b)
{
return (a | b) ^ a;
}
And:
int f1(int a, int b)
{
return (a | ~b) ^ a;
}
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #22 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #20) > What then happens is: > > expr.cc::do_store_flag() > expmed.cc::emit_store_flag_force() > expmed.cc::emit_store_flag() > expmed.cc::emit_store_flag_1() > > the latter then does: > > if (STORE_FLAG_VALUE == 1 || normalizep) > /* If we are supposed to produce a 0/1 value, we want to do >a logical shift from the sign bit to the low-order bit; for >a -1/0 value, we do an arithmetic shift. */ > op0 = expand_shift (RSHIFT_EXPR, int_mode, op0, > GET_MODE_BITSIZE (int_mode) - 1, > subtarget, normalizep != -1); > > "normalizep" is true because ops->type has a precision of 1, and > STORE_FLAG_VALUE is the default of 1. > > Nowhere is there any cost computation or consideration whether extzv could > do the trick. Thanks for tracking down where the shift is expanded to. Let me try to use extract_bit_field there instead (which should produce the better code).
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 --- Comment #3 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #1) > Also fails with "-mtune=znver1 -mavx": > > Program received signal SIGSEGV, Segmentation fault. > 0x004048ef in func_21 (p_22=0x41b330 , p_23=0, p_24=8) at > runData/keep/in.11.c:597 > 597 in runData/keep/in.11.c > (gdb) disass $pc-10, $pc+10 > Dump of assembler code from 0x4048e5 to 0x4048f9: >0x004048e5 : mov(%rax),%rdx >0x004048e8 : mov-0x1378(%rbp),%rax > => 0x004048ef : vmovdqa (%rdx),%ymm0 >0x004048f3 : vmovdqa %ymm0,(%rax) >0x004048f7 : vmovdqa 0x20(%rdx),%ymm0 > End of assembler dump. > (gdb) p/x $rdx > $3 = 0x41a824 > > Unaligned access. After some more analysis, the above *IS* unaligned access. At the end of func_21, we have: => 0x004048ef <+8170>: vmovdqa (%rdx),%ymm0 0x004048f3 <+8174>: vmovdqa %ymm0,(%rax) 0x004048f7 <+8178>: vmovdqa 0x20(%rdx),%ymm0 0x004048fc <+8183>: vmovdqa %ymm0,0x20(%rax) 0x00404901 <+8188>: vmovdqa 0x40(%rdx),%ymm0 0x00404906 <+8193>: vmovdqa %ymm0,0x40(%rax) 0x0040490b <+8198>: vmovdqa 0x60(%rdx),%ymm0 0x00404910 <+8203>: vmovdqa %ymm0,0x60(%rax) which looks like a memory copy to me. Unfortunately, the address is unaligned: (gdb) p/x $rdx $2 = 0x41a824 Changing the above vmovdqa insns to vmovdqu results in a successful run.
[Bug rtl-optimization/109992] New: Addition/subtraction to the last bitfield of a struct can be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Bug ID: 109992
Summary: Addition/subtraction to the last bitfield of a struct
can be optimized
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
For an unsigned bit field:
```
struct foo
{
unsigned a : 3;
unsigned b : 29;
};
void
bad_add(struct foo* p, unsigned add)
{
p->b += add;
}
```
GCC:
```
bad_add:
mov eax, DWORD PTR [rdi]
mov edx, eax
and eax, 7
shr edx, 3
add edx, esi
sal edx, 3
or eax, edx
mov DWORD PTR [rdi], eax
ret
```
Clang:
```
bad_add:# @bad_add
shl esi, 3
add dword ptr [rdi], esi
ret
```
It looks like GCC extracts the bitfield first, performs the addition, then
inserts it back.
The result is almost the same for a signed bitfield, but not exacting the
bitfield first is subject to overflows, so it may be a different story.
[Bug rtl-optimization/109992] Addition/subtraction to the last bitfield of a struct can be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992 --- Comment #1 from Andrew Pinski --- As an aside: it is funny how x86 does not have a bits insert instruction yet (while almost all RISC targets have that now).
[Bug tree-optimization/109992] Addition/subtraction to the last bitfield of a struct can be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|rtl-optimization|tree-optimization
[Bug tree-optimization/109992] Addition/subtraction to the last bitfield of a struct can be optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-26 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- After my lowering pass (little-endian) we have: _1 = BIT_FIELD_REF <_9, 29, 3>; _2 = (unsigned int) _1; _3 = _2 + add_7(D); _4 = () _3; _11 = BIT_INSERT_EXPR <_9, _4, 3 (29 bits)>; Which I suspect we could pattern match to: _t = add_7 << 3; _11 = _9 + _t; iff 3+29 == 32(int) Big-endian (with fields a and b swapped order in the source): _9 = MEM[(struct foo *)p_6(D)]; _1 = BIT_FIELD_REF <_9, 29, 0>; _2 = (unsigned int) _1; _3 = _2 + add_7(D); _4 = () _3; _11 = BIT_INSERT_EXPR <_9, _4, 0 (29 bits)>; Similar pattern matching, just using 0 for the offset rather than 3 ...
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #23 from Georg-Johann Lay ---
Thank you so much for looking into this.
For the test case from comment #21 though, the problem is somewhere in tree
optimizations.
> unsigned char lfsr32_mpp_ge0 (unsigned long number)
> {
> unsigned char b = 0;
> if (number >= 0) b--;
> if (number & (1UL << 29)) b++;
> if (number & (1UL << 13)) b++;
>
> return b;
> }
The -fdump-tree-optimized dump reads:
;; Function lfsr32_mpp_ge0 (lfsr32_mpp_ge0, funcdef_no=0, decl_uid=1880,
cgraph_uid=1, symbol_order=0)
unsigned char lfsr32_mpp_ge0 (long unsigned int number)
{
unsigned char b;
long unsigned int _1;
long unsigned int _2;
_Bool _3;
unsigned char _8;
_Bool _9;
unsigned char _10;
unsigned char _11;
[local count: 1073741824]:
_1 = number_5(D) & 536870912;
_2 = number_5(D) & 8192;
if (_2 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
_9 = _1 == 0;
_10 = (unsigned char) _9;
_11 = -_10;
goto ; [100.00%]
[local count: 536870913]:
_3 = _1 != 0;
_8 = (unsigned char) _3;
[local count: 1073741824]:
# b_4 = PHI <_11(3), _8(4)>
return b_4;
}
The ANDs are expanded by expand_binop() and later passes have to deal with the
32-bit arithmnetic. combine finds one combination of andsi3 into
"*sbrx_and_branch_split" with mode=si, but apart from that the mess still
lives in asm.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55151|0 |1
is obsolete||
--- Comment #50 from Jakub Jelinek ---
Created attachment 55169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55169&action=edit
gcc14-bitint-wip.patch
Update, this time with addition of libgcc _BitInt multiplication libcall (but
not really wiring it on the compiler side yet, that would be part of the new
_BitInt lowering pass).
The function currently is
void __mulbitint3 (__bitint_limb *ret, int retprec, const __bitint_limb *u, int
uprec, const __bitint_limb *v, int vprec);
which allows mixing different precisions (at compile time, or at runtime using
the bitint_reduce_prec function); while in GIMPLE before _BitInt lowering pass
MULT_EXPR
will obviously have same precision for result and both operands, the lowering
pass could
spot zero or sign extensions from narrower _BitInts for the operands, or VRP
could figure out smaller ranges of values for the operands.
Negative uprec or vprec would mean the operand is sign extended from precision
-[uv]prec, positive it is zero extended from [uv]prec.
u/v could be the same or overlapping, but as the function writes result before
consuming all inputs, doesn't allow aliasing between operands and return value.
Also, at least in the x86-64 psABI, _BitInt(N) for N < 64 is special and it
isn't expected this function would be really used for multiplication of such
_BitInts, but of course if say multiplicating say _BitInt(512) by _Bitint(24),
it is expected the lowering pass would push those 24 bits into a 64-bit 64-bit
aligned limb and pass 24 for that operand.
For inputs it assumes bits above precision but still within a limb are
uninitialized (and so zero or sign extends when reading it), for the output it
always writes full limb (with hopefully proper zero/sign extensions).
The implemented algorith is the base school book multiplication, if really
needed, we could do Karatsuba for larger inputs.
What do you think about this API?
Shall I continue and create similar API for divmod?
Also, wonder what to do about _BitInt(N) in __builtin_mul_overflow{,_p}. One
option would be to say that negative retprec is a request to return a nonzero
result for the overflow case, but wonder how much larger the routine would be
in that case. Or if we
should have two, one for multiplication and one for multiplication with
overflow checking. Yet another possibility is to do a dumb thing on the
compiler side, call the multiplication with a temporary result as large that it
would never overflow and check for the overflow on the caller side.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #51 from Jakub Jelinek ---
Note, I've only tested it so far on
_BitInt(256) a = 0x1234ab461289cdab8d111007b461289cdab8d1wb;
_BitInt(256) b = 0x2385eabcd072311074bcaa385eabcd07111007b46128wb;
_BitInt(384) c = (_BitInt(384)) 0x1234ab461289cdab8d111007b461289cdab8d1wb *
0x2385eabcd072311074bcaa385eabcd07111007b46128wb;
_BitInt(384) d;
extern void __mulbitint3 (unsigned long *, int, const unsigned long *, int,
const unsigned long *, int);
void
foo ()
{
__mulbitint3 (&d, 384, &a, 256, &b, 196);
}
multiplication, nothing else, guess it will be easier to test it when we can
emit from the compiler. And obviously no testing of the big endian limb
ordering handling until we add some arch that will support it (if we do that at
all).
[Bug libstdc++/109993] New: std::regex("\\a", std::regex::basic) does not diagnose invalid BRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109993
Bug ID: 109993
Summary: std::regex("\\a", std::regex::basic) does not diagnose
invalid BRE
Product: gcc
Version: 14.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
int main()
{
std::regex("\\a", std::regex::basic);
}
This should throw a std::regex_error exception.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03
"The interpretation of an ordinary character preceded by an unescaped
( '\\' ) is undefined, except for: [...]"
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
[Bug 102445] [meta-bug] std::regex issues
[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #14 from Martin Uecker --- Maybe. On the other hand, I wonder whether a struct with FAM should not rather always have the same size, and alignment, and representation as the corresponding struct with a conventional array. This would conceptually be cleaner, easier to understand, and less error prone.
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 --- Comment #4 from David Binderman --- Original git range was 123 commits. Current bisect range is g:89ba8366fe12fd2d .. g:23be9d78f4bcd773, which is 31 commits. Trying 5b30e9bc211fede0.
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #4 from Bruno Haible ---
> >
> > char *new_pool = (char *) realloc (string_space,
> > new_size);
> > if (new_pool == ((void *)0))
> > goto out;
> > if (__builtin_expect (string_space != new_pool, 0))
> > {
> > size_t i;
> > for (i = 0; i < nmap; i++)
> > {
> > map[i].alias += new_pool - string_space;
> > map[i].value += new_pool - string_space;
> > }
> > }
> > string_space = new_pool;
> Also I think `new_pool - string_space` is undefined really. That is
> subtracting two unrelated arrays is undefined. You can only compare equality
> on them.
That is the only way of keeping track of pointers _into_ the string_space area,
when it is reallocated. How else would you want to do it?
[Bug preprocessor/109994] New: Issue a diagnostic when a C++ file defines a macro that hides a keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994 Bug ID: 109994 Summary: Issue a diagnostic when a C++ file defines a macro that hides a keyword Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- The C++ standard says this is undefined: #define new foo It might be nice if the preprocessor had a warning about it. [macro.names] A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 4, or to the attribute-tokens described in 9.12, except that the names likely and unlikely may be defined as function-like macros (15.6).
[Bug preprocessor/109994] Issue a diagnostic when a C++ file defines a macro that hides a keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-05-26
[Bug tree-optimization/109985] __builtin_prefetch ignored by GCC 12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-05-26 --- Comment #1 from Andrew Pinski --- There are only two __builtin_prefetch in .optimized for GCC 12. This is definitely going to be hard to debug ... Can you attach the preprocessed source?
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 --- Comment #5 from Bruno Haible --- Created attachment 55170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55170&action=edit test case bar2.c Find attached a modified test case. I changed the code to map[i].alias = new_pool + (map[i].alias - string_space); map[i].value = new_pool + (map[i].value - string_space); so that it subtracts pointers into the old string_space, producing an integer, and adding that integer to new_pool. It produces the same warning (even twice, apparently because there is no common subexpression between the two lines any more): $ gcc -Wall -O2 -S bar2.c bar2.c: In function ‘read_alias_file’: bar2.c:123:67: warning: pointer may be used after ‘realloc’ [-Wuse-after-free] 123 | map[i].value = new_pool + (map[i].value - string_space); | ~~^~~ bar2.c:114:45: note: call to ‘realloc’ here 114 | char *new_pool = (char *) realloc (string_space, new_size); | ^~~~ bar2.c:122:67: warning: pointer may be used after ‘realloc’ [-Wuse-after-free] 122 | map[i].alias = new_pool + (map[i].alias - string_space); | ~~^~~ bar2.c:114:45: note: call to ‘realloc’ here 114 | char *new_pool = (char *) realloc (string_space, new_size); | ^~~~
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 --- Comment #6 from Andrew Pinski --- (In reply to Bruno Haible from comment #4) > That is the only way of keeping track of pointers _into_ the string_space > area, when it is reallocated. How else would you want to do it? You could use intptr_t casting to do the subtraction ...
[Bug preprocessor/109994] Issue a diagnostic when a C++ file defines a macro that hides a keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994 --- Comment #1 from Andrew Pinski --- There are definitly testcases in GCC's testsuite which does this all the time. #define int ...
[Bug preprocessor/109994] Issue a diagnostic when a C++ file defines a macro that hides a keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994 --- Comment #2 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > There are definitly testcases in GCC's testsuite which does this all the > time. > #define int ... Yeah, it shouldn't be in -Wall, and it's not a required diagnostic for conformance. But it might be nice. Not a priority though.
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 --- Comment #5 from David Binderman --- Current git range is g:193fccaa5c3525e9 .. g:5b30e9bc211fede0, which is 8 commits.
[Bug preprocessor/109994] Issue a diagnostic when a C++ file defines a macro that hides a keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Not just testcases, libgcc.h does that too (though, sure, that is C).
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 --- Comment #6 from David Binderman --- This commit looks highly likely: commit eef81eefcdc2a58111e50eb2162ea1f5becc8004 Author: Jan Hubicka Date: Thu Dec 22 10:55:46 2022 +0100 Zen4 tuning part 2
[Bug middle-end/109995] New: Bogus warning about __builtin_memset, from -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995 Bug ID: 109995 Summary: Bogus warning about __builtin_memset, from -Wstringop-overflow Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 55171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55171&action=edit test case bar.c In the attached program, -Wall produces a warning "warning: ‘__builtin_memset’ specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]", in a function that does not invoke 'memset' nor '__builtin_memset'. With gcc 10.4.0: $ gcc -O2 -Wall -S bar.c In function ‘memset_small’, inlined from ‘wrap’ at bar.c:242:1: bar.c:249:17: warning: ‘__builtin_memset’ specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 249 | do *++p = c; while (--n > 0); |~^~~ With gcc 11.3.0, 12.3.0, 13.1.0: $ gcc -O2 -Wall -S bar.c In function ‘memset_small’, inlined from ‘memset_small’ at bar.c:242:1, inlined from ‘wrap’ at bar.c:590:19: bar.c:249:17: warning: ‘__builtin_memset’ specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 249 | do *++p = c; while (--n > 0); |~^~~
[Bug middle-end/109995] Bogus warning about __builtin_memset, from -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995 --- Comment #1 from Andrew Pinski --- do *++p = c; while (--n > 0); is turned into memset during optimizations.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #10 from Marek Polacek ---
So I have
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27969,6 +27969,13 @@ value_dependent_expression_p (tree expression)
else if (TYPE_REF_P (TREE_TYPE (expression)))
/* FIXME cp_finish_decl doesn't fold reference initializers. */
return true;
+ /* We have a constexpr variable and we're processing a template. When
+there's lifetime extension involved (for which finish_compound_literal
+used to create a temporary), we'll not be able to evaluate the
+variable until instantiating, so pretend it's value-dependent. */
+ else if (DECL_DECLARED_CONSTEXPR_P (expression)
+ && !TREE_CONSTANT (expression))
+ return true;
return false;
case DYNAMIC_CAST_EXPR:
but that breaks
struct foo { };
template void fnc() { }
void
test()
{
static constexpr foo a;
fnc();
}
with:
$ ./cc1plus -quiet nontype-auto16.C
nontype-auto16.C:6:31: warning: ‘void fnc() [with const foo& F = a]’ used but
never defined
6 | template void fnc() { }
| ^~~
nontype-auto16.C:13:1: internal compiler error: Segmentation fault
13 | }
| ^
0x19a5624 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:314
0x7fe161facb1f ???
/usr/src/debug/glibc-2.36-9.fc37.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xcbfe74 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3795
0x12c2224 symbol_table::decl_assembler_name_hash(tree_node const*)
/home/mpolacek/src/gcc/gcc/symtab.cc:84
The warning is obviously wrong and the cause for the ICE, I'd say. test isn't
a function template but uses_template_parms / verify_unstripped_args set p_t_d,
so we still reach the new code.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #52 from Jakub Jelinek --- (In reply to H.J. Lu from comment #14) > (In reply to jos...@codesourcery.com from comment #13) > > https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI > > for 32-bit x86. I don't know if there are other psABIs with public issue > > trackers where such issues can be filed (but we'll need some sensible > > default anyway for architectures where we can't get an ABI properly > > specified in an upstream-maintained ABI document). > > ia32 psABI will follow x86-64 psABI. Is it a good idea to use 64-bit limbs and 64-bit alignment for the ia32 ABI? I mean, it is fine to use that _BitInt(N) for N 33..64 has size/alignment/passing of long long, but wonder if for N > 64 the ABI shouldn't use 32-bit limbs, 32-bit alignments and passing as struct containing the 32-bit limbs.
[Bug tree-optimization/109985] __builtin_prefetch ignored by GCC 12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985 Christian Mazakas changed: What|Removed |Added CC||christian.mazakas at gmail dot com --- Comment #2 from Christian Mazakas --- Created attachment 55172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55172&action=edit Preprocessed source from the relevant godbolt.org link This is the preprocessed output on my machine, generated using the code from the relevant benchmark and develop Branch of Unordered Let me know if it doesn't provide enough information or if more is required.
[Bug tree-optimization/109985] __builtin_prefetch ignored by GCC 12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982 David Binderman changed: What|Removed |Added CC||jh at suse dot cz --- Comment #7 from David Binderman --- As expected: $ git bisect bad eef81eefcdc2a581 eef81eefcdc2a58111e50eb2162ea1f5becc8004 is the first bad commit commit eef81eefcdc2a58111e50eb2162ea1f5becc8004 Author: Jan Hubicka Date: Thu Dec 22 10:55:46 2022 +0100 Zen4 tuning part 2
[Bug target/109984] FAIL: insn-modes.h: No such file or directory (x86_64-apple-darwin22.4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109984 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This is not the right place to ask about a bug in your front-end. If you use coretypes.h you need to specify $(CORETYPES_H) as a depedency on those object files.
[Bug tree-optimization/109985] __builtin_prefetch ignored by GCC 12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from Jakub Jelinek --- Since r12-5236-g5aa91072e24c1e16 the -O3 assembly contains just 2 prefetches rather than 4.
[Bug preprocessor/109988] -iwithprefix doesn't add folder to end of search list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-26 Keywords||documentation Component|c++ |preprocessor Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- It has been the same as -isystem since at least r0-21114-g0b22d65c9a10ce (March 1999). The documentation was changed (added to) at r0-35796-gf3c9b8530c78ce (June 2001) to specify the same as -idirafter even though the implementation was something different I don't know what the correct thing to do really since it has been almost 22 years of having the documentation not match the implementation ... Maybe just update the documentation Confirmed either way.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #42 from Oleg Endo --- (In reply to Alexander Klepikov from comment #41) > > Thank you! I have an idea. If it's impossible to defer initial optimization, > maybe it's possible to emit some intermediate insn and catch it and optimize > later? This is basically what is supposed to be happening there already. However, it's a bit of a dilemma. 1) If we don't have a dynamic shift insn and we smash the constant shift into individual stitching shifts early, it might open some new optimization opportunities, e.g. by sharing intermediate shift results. Not sure though if that actually happens in practice though. 2) Whether to use the dynamic shift insn or emit a function call or use stitching shifts sequence, it all has an impact on register allocation and other instruction use. This can be problematic during the course of RTL optimization passes. 3) Even if we have a dynamic shift, sometimes it's more beneficial to emit a shorter stitching shift sequence. Which one is better depends on the surrounding code. I don't think there is anything good there to make the proper choice. Some other shift related PRs: PR 54089, PR 65317, PR 67691, PR 67869, PR 52628, PR 58017 > > BTW, have you tried it on a more recent GCC? There have also been some > > optimizations in the middle-end (a bit more backend independent) for this > > kind of thing. > > I tried 13.1 about week or two ago with the same result. > Good to know. Thanks for checking it!
[Bug c/109996] New: csmith: -O2 -fno-strict-aliasing causing run time trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996 Bug ID: 109996 Summary: csmith: -O2 -fno-strict-aliasing causing run time trouble Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 55173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55173&action=edit C source code The attached C code does this: [dcb38@fedora foundBugs]$ ../results/bin/gcc -w -O1 bug924.c runData/keep/in.45.c: In function ‘func_5’: runData/keep/in.45.c:434:18: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6 [dcb38@fedora foundBugs]$ ./a.out checksum = 7AACDAF2 [dcb38@fedora foundBugs]$ ../results/bin/gcc -w -O2 bug924.c runData/keep/in.45.c: In function ‘func_5’: runData/keep/in.45.c:434:18: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6 [dcb38@fedora foundBugs]$ ./a.out Segmentation fault (core dumped) Normally, -fno-strict-aliasing helps, but not here: [dcb38@fedora foundBugs]$ ../results/bin/gcc -w -O2 -fno-strict-aliasing bug924.c runData/keep/in.45.c: In function ‘func_5’: runData/keep/in.45.c:434:18: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6 [dcb38@fedora foundBugs]$ ./a.out Segmentation fault (core dumped) The bug seems to have existed for some time: $ ../results.20220515/bin/gcc -w -g -O2 -fno-strict-aliasing bug924.c runData/keep/in.45.c: In function ‘func_5’: runData/keep/in.45.c:434:18: note: the ABI for passing parameters with 32-byte alignment has changed in GCC 4.6 [dcb38@fedora foundBugs]$ ./a.out Segmentation fault (core dumped) [dcb38@fedora foundBugs]$
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #8 from Alexander Monakov ---
Also reproducible with -march=haswell, and works with
-mmove-max=128 -mstore-max=128 -mtune-ctrl=^sse_unaligned_store_optimal
added. I would guess the real culprit is commit r12-2666-g29f0e955c97 ("x86:
Update piecewise move and store") like in PR 109780.
[Bug c++/109997] New: __is_assignable(int, IncompleteType) should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997 Bug ID: 109997 Summary: __is_assignable(int, IncompleteType) should be rejected Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 71579 Target Milestone: --- struct S; bool b = __is_assignable(int, S); This should be rejected: The precondition for std::is_assignable is: "T and U shall be complete types, cv void, or arrays of unknown bound." Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579 [Bug 71579] type_traits miss checks for type completeness in some traits
[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579 --- Comment #25 from Jonathan Wakely --- Some missing completeness checks: std::assignable We don't enforce precondition that both types are complete types, cv void, or arrays of unknown bound. Filed as PR c++/109997 std::common_type Our impl is SFINAE-friendly, but the standard has a precondition that all types in the pack are complete, cv void, or array of unknown bound.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 --- Comment #11 from Marek Polacek --- We never instantiated fnc because mark_used checks /* Check this too in case we're within instantiate_non_dependent_expr. */ if (DECL_TEMPLATE_INFO (decl) && uses_template_parms (DECL_TI_ARGS (decl))) return true; and here uses_template_parms says yes because value_dependent_expression_p says 'a' is value-dep. Note we can't use in_template_function in v_d_e_p.
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 --- Comment #6 from Sergei Trofimovich --- Created attachment 55174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55174&action=edit packet-rnsap-shrunk-slightly.c.i.xz packet-rnsap-shrunk-slightly.c.i.xz is a slightly shrunk version of the original. It exhibits 10x slowdown and has a reasonable compilation completion time. Might be useful to explore as is or bisect gcc: $ gcc -O2 -c packet-rnsap-shrunk-slightly.c.i -o bug.o -fipa-pta -Wno-deprecated-declarations -fno-ipa-pta >/dev/null 2>&1 real0m0,657s user0m0,626s sys 0m0,026s $ gcc -O2 -c packet-rnsap-shrunk-slightly.c.i -o bug.o -fipa-pta -Wno-deprecated-declarations -fipa-pta >/dev/null 2>&1 real0m6,120s user0m6,065s sys 0m0,045s -ftime-report says 'ipa points-to' takes 88%. -fdump-ipa-all-details creates 2.0G bug.i.092i.pta2 file (the rest of files are unred 5M). I suspect it's a pathology in solving a huge `proto_reg_handoff_rnsap()` graph. Some variables have up to 5000 PT entries.
[Bug c++/109997] __is_assignable(int, IncompleteType) should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last reconfirmed||2023-05-26
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Marek Polacek ---
Same for std::is_constructible. So presumably we want something like
--- a/gcc/cp/method.cc
+++ b/gcc/cp/method.cc
@@ -2173,7 +2173,10 @@ constructible_expr (tree to, tree from)
static tree
is_xible_helper (enum tree_code code, tree to, tree from, bool trivial)
{
- to = complete_type (to);
+ to = complete_type_or_else (to, NULL_TREE);
+ from = complete_type_or_else (from, NULL_TREE);
+ if (!from || !to)
+return error_mark_node;
deferring_access_check_sentinel acs (dk_no_deferred);
if (VOID_TYPE_P (to) || ABSTRACT_CLASS_TYPE_P (to)
|| (from && FUNC_OR_METHOD_TYPE_P (from)
but I'd have to test std::is_constructible with a parameter pack as well.
[Bug fortran/109998] New: [OpenMP] TR12/5.0/5.1 - permit structure elements with '!$OMP ALLOCATORS' (and !$OMP ALLOCATE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109998 Bug ID: 109998 Summary: [OpenMP] TR12/5.0/5.1 - permit structure elements with '!$OMP ALLOCATORS' (and !$OMP ALLOCATE) Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Cf. r14-1301-gd64e8e1224708e7f5b87c531aeb26f1ed07f91ff and in particular in openmp.cc the comment: Note that the executable ALLOCATE directive permits structure elements only in OpenMP 5.0 and 5.1 but not longer in 5.2. See also the comment on the 'omp allocators' directive below. The accidental change was reverted for OpenMP TR12, permitting them again. See also gfc_match_omp_allocators. Hence, structure elements are rejected for now, also to make resolving OMP_LIST_ALLOCATE simpler (check for duplicates, same symbol in Fortran allocate stmt). TODO: Permit structure elements. EXPECTED: What the TODO says. For TR12 (OpenMP Spec Issue 3437), the description in the "allocators directive" section was changed to state: "The list items that appear in an *allocate* clause may include structure elements." (It does not talk about the *allocate* directive any more as TR11/TR12/6.0 removed deprecated features.)
[Bug c/109999] New: [OpenMP] Bogus error message: talks about '"#pragma omp" clause' instead of '"target" clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Bug ID: 10 Summary: [OpenMP] Bogus error message: talks about '"#pragma omp" clause' instead of '"target" clause Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: diagnostic, openmp Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I just spotted with gcc and g++; IMHO the error message is misleading/wrong/odd, however, it does not seem to be a regression. Namely I get: tests/5.0/allocate/test_allocate_on_device.c:27:43: error: expected ‘#pragma omp’ clause before ‘uses_allocators’ 27 | #pragma omp target map(tofrom: errors, A) uses_allocators(omp_default_mem_alloc) | ^~~ EXPECTED: instead of "expected '#pragma omp' clause" it should be show: "expected 'target' clause". Found when compiling: g++ --free-line-length-none -fopenmp -I ompvv tests/5.0/allocate/test_allocate_on_device.c which is part of https://github.com/SOLLVE/sollve_vv
[Bug c/109999] [OpenMP] Bogus error message: talks about '"#pragma omp" clause' instead of '"target" clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #1 from Andrew Pinski ---
: In function 'test_allocate_on_device':
:27:43: error: expected '#pragma omp' clause before 'uses_allocators'
27 | #pragma omp target map(tofrom: errors, A)
uses_allocators(omp_default_mem_alloc)
| ^~~
It is because uses_allocators is not implemented yet.
If you do this:
```
int test_allocate_on_device() {
#pragma omp target hhh
for(int i = 0;i < 10;i++);
}
```
GCC will produce a similar error message.
If you replace hhh with simd, it will work.
I suspect the error message is correct in the sense an omp clause there is
still valid too. it does not know if it will be either a target or a normal
clause .
[Bug c++/109991] stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991 --- Comment #3 from igk --- (In reply to Andrew Pinski from comment #2) > Dup of bug 98675. > > *** This bug has been marked as a duplicate of bug 98675 *** Thanks for looking into this. I haven't quite understood though. I'm trying to see if I can find what you're saying that it should be rejected in the C++ 14 standard (the version I have). The closest things I can find are the following. Are they the relevant parts? ``` For a non-template, non-defaulted constexpr function or a non-template, non-defaulted, non-inheriting constexpr constructor, if no argument values exist such that an invocation of the function or constructor could be an evaluated subexpression of a core constant expression (5.19), the program is ill-formed; no diagnostic required. ``` where (5.19) includes ``` A conditional-expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine (1.9), would evaluate one of the following expressions: ... - an operation that would have undefined behavior,.. ``` In my example, the function takes no arguments so there are no argument values "such that an invocation of the function or constructor could be an evaluated sub-expression of a core constant expression". This would make my program "ill-formed, no diagnostic required". I interpret this as saying the compiler isn't required to reject the code. Perhaps I'm on the wrong track, but I'm wondering, isn't such UB something sanitizer aims to catch? Also, (not an issue with sanitizer) to me it seems odd that GCC would do constexpr evaluation when "BadWrapUse c;" is not declared as a constexpr variable, rather than not avoiding it because it is not valid.
[Bug c++/109991] stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991 --- Comment #4 from Andrew Pinski --- (In reply to igk from comment #3) > (In reply to Andrew Pinski from comment #2) > > Dup of bug 98675. > > > > *** This bug has been marked as a duplicate of bug 98675 *** > > Thanks for looking into this. I haven't quite understood though. Let me reword of what is going on and why it is still is a dup. So the constexpr should be ignored because it is undefined code. But since GCC does not detect the undefineness yet (this is what PR 98675 is about), GCC decides that it is still a constexpr and evaluates it at compile time and removes the ability for the sanitizer to detect the undefinedness at runtime.
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 --- Comment #7 from Sergei Trofimovich --- Original packet-rnsap.c.i.xz takes 27 minutes to compile for me. The hack below cuts this time down to 9 minutes (slashes 60% of runtime). The considerable amount of time is spent looking up the bitmaps for graph edges to extract and solve PT facts. I'd say there is a room for micro-optimization to turn bitmap to something slightly smarter than a linked list. It will not improve the runtime too much. Another option could be to put a limit on edge count (say, controlled by a `param`) which `gcc` could use to fallback on conservative value. --- a/gcc/bitmap.h +++ b/gcc/bitmap.h @@ -283,7 +283,7 @@ typedef unsigned long BITMAP_WORD; /* Number of words to use for each element in the linked list. */ #ifndef BITMAP_ELEMENT_WORDS -#define BITMAP_ELEMENT_WORDS ((128 + BITMAP_WORD_BITS - 1) / BITMAP_WORD_BITS) +#define BITMAP_ELEMENT_WORDS ((8192 + BITMAP_WORD_BITS - 1) / BITMAP_WORD_BITS) #endif /* Number of bits in each actual element of a bitmap. */
[Bug ipa/109983] [12/13/14 regression] Wireshark compilation hangs with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983 --- Comment #8 from Andrew Pinski --- (In reply to Sergei Trofimovich from comment #7) > Original packet-rnsap.c.i.xz takes 27 minutes to compile for me. > > The hack below cuts this time down to 9 minutes (slashes 60% of runtime). Or maybe it should be moved over to use sbitmap rather than bitmap ...
[Bug c++/109991] stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991 --- Comment #5 from igk --- OK, becoming clearer, thanks. I'm just hoping for this to be diagnosed in some way. IIUC basically GCC doesn't diagnose the UB so it proceeds with constexpr eval just because it can, or so it thinks, and in the process makes it impossible for sanitizer to catch anything. Assuming that gets fixed some day, then GCC might as well diagnose the issue itself and hence no need for sanitizer to do anything.
[Bug c++/110000] New: GCC should implement exclude_from_explicit_instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Bug ID: 11 Summary: GCC should implement exclude_from_explicit_instantiation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nikolasklauser at berlin dot de Target Milestone: --- `exclude_from_explicit_instantiation` is an attribute implemented by clang. It tells the compiler that a function should not be part of an explicit instantiation. This allows libraries to have greater control over which functions are part of their ABI and which aren't. It is used extensively in libc++ to keep the ABI surface as small as possible. Currently, libc++ uses always_inline if exclude_from_explicit_instantiation isn't available, resulting in almost every function in the library being declared as always_inline. Replacing always_inline with exclude_from_explicit_instantiation would approximately halve the time it takes to run the libc++ test suite with GCC. (removing always_inline brings the time down to about the same as clang takes)
[Bug target/109982] csmith: x86_64: znver1 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC||hjl.tools at gmail dot com
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-26
--- Comment #9 from H.J. Lu ---
[hjl@gnu-cfl-3 pr109982]$ cat x.c
struct S0 {
long long int f0;
} __attribute__((aligned(128)));
int padding = 1;
static struct S0 g_2415 __attribute__((aligned(4))) = {-1L};
static struct S0 *g_2500 __attribute__((visibility("internal"), used)) =
&g_2415;
const struct S0 func_21 ()
{
return *g_2500;
}
int
main ()
{
func_21 ();
return 0;
}
[hjl@gnu-cfl-3 pr109982]$ make
gcc -mtune=haswell -mavx -g -w -c -o x.o x.c
gcc -mtune=haswell -mavx -g -w -o x x.o
./x
make: *** [Makefile:16: all] Segmentation fault (core dumped)
[hjl@gnu-cfl-3 pr109982]$
