[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #11 from Pekka S --- Hi, that indeed does solve the build issue, though I only tried using --disable-analyzer. I've been using a similar patch up until this point, but retired my local patch in favour of this. Thanks!
[Bug lto/98275] New: -flto=auto fails if nthreads_var is zero, must not pass -j0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98275
Bug ID: 98275
Summary: -flto=auto fails if nthreads_var is zero, must not
pass -j0
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Host: mingw64
Hi.
When using `-flto=auto' if the number of threads is not detected, i.e.
`nthreads_var' equals to zero, lto-wrapper must not pass -j0 to GNU make as -j
expects a positive, non-zero integer (if any given).
>From GNU make manual: ``If the ‘-j’ option is followed by an integer, this is
the number of recipes to execute at once; this is called the number of job
slots. If there is nothing looking like an integer after the ‘-j’ option, there
is no limit on the number of job slots.''.
gcc/lto-wrapper.c:
2001 snprintf (jobs, 31, "-j%ld",
2002 auto_parallel ? nthreads_var : parallel);
$ make -j0
make: the '-j' option requires a positive integer argument
Tried GNU make 4.2.1 (2016 vintage) and 4.2.93 (2020). For the latest trunk
argument parsing happens at src/main.c around line 2961 [1]; It basically does
``int i = atoi(arg); if (i < 1 || not-all-chars-are-digits) { handle-bad-arg
}''.
[1] https://git.savannah.gnu.org/cgit/make.git/tree/src/main.c#n2961
[Bug lto/98275] -flto=auto fails if nthreads_var is zero, must not pass -j0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98275 --- Comment #4 from Pekka S --- (I wrote this prior the ticked was modifed and the patch committed.) Thanks. Applied the patch on the latest trunk, built aarch64-none-gcc cross compiler (mingw64). Using -flto=auto -v reports `LTO parallelism level set to 1' and `make -f -j1 all'; Linking now succeeds. Tested using GNU make 4.2.93 and 4.3 (msys2). I do not know whether or not the number of processors should be actually detectable. I presume I'll be simply using -flto=N (N>1) as it appears to work just fine. As a side note behaviour is now slightly different between -flto=auto if nthreads_var<=1 and -flto=N where N<=1.
[Bug c++/98343] New: [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98343
Bug ID: 98343
Summary: [11 Regression] ICE in in relocate_ptrs, at
ggc-common.c:363 [PCH and C++20 std::source_location?]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Host: x86_64-w64-mingw32 x86_64-linux-gnu
Target: aarch64-none-elf
Created attachment 49786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49786&action=edit
An input header using std::source_location::current().
Hi.
Using GCC11 trunk built on 15.12.2020 @ x86_64-w64-mingw32 and 16.12.2020 @
x86_64-linux-gnu (sorry, unable to the latest trunk due to PR98300).
When attempting to precompile the following input header file GCC will ICE at
ggc-common. However that happens only, and only if, certain warnings are
enabled. `-Wall' will trigger this, and to be more precise any of the
following warnings: `-Wformat', `-Wnonnull' or `-Wrestrict'.
I do know if `std::source_location' is a red herring, or the warning flags, but
using a (large) real life file when the ICE occurs all symptoms point (dumping
a corresponding troublesome hash table) to locations which use
`std::source_location::current()'. Again, without `-Wall', PCH is compiled
just fine. (The resulting GCH is over 128 MB.)
I'm able to reproduce this on both Windows and Linux. I quickly tried a GCC10
(Windows) GCC9 (Linux) and they work just fine with that input file (though
those where not aarch64 targets; I presume this really has nothing to with the
target).
$ cat pch.hpp
#if __has_include()
#include
#else
#include
namespace std { using namespace experimental; }
#endif
extern void location_fun(std::source_location loc =
std::source_location::current());
$ aarch64-none-elf-g++ -std=c++20 -c pch.hpp -Wall
pch.hpp:2:85: internal compiler error: in relocate_ptrs, at ggc-common.c:363
2 | extern void location_fun(std::source_location loc =
std::source_location::current());
$ aarch64-none-elf-g++ -std=c++20 -c pch.hpp -Wall -wrapper gdb,--args
(gdb) break fancy_abort
(gdb) run
Thread 1 hit Breakpoint 1, fancy_abort (
file=0x1eefb00 <(anonymous namespace)::pass_data_rtl_pre+576>
"<...>/src/gcc/gcc/ggc-common.c", line=363, function=0x1eefbc2 <(anonymous
namespace)::pass_data_rtl_pre+770> "relocate_ptrs")
at <...>/src/gcc/gcc/diagnostic.c:1835
(gdb) bt
#0 fancy_abort (
file=0x1eefb00 <(anonymous namespace)::pass_data_rtl_pre+576>
"<...>/src/gcc/gcc/ggc-common.c", line=363, function=0x1eefbc2 <(anonymous
namespace)::pass_data_rtl_pre+770> "relocate_ptrs")
at <...>/src/gcc/gcc/diagnostic.c:1835
#1 0x01c15cc8 in relocate_ptrs (ptr_p=0x210ea9b0, state_p=)
at <...>/src/gcc/gcc/ggc-common.c:351
#2 relocate_ptrs (ptr_p=0x210ea9b0, state_p=)
at <...>/src/gcc/gcc/ggc-common.c:351
#3 0x00471ea6 in ggc_remove::pch_nx
(cookie=0x1cf0fab0,
op=0x8d75e0 , p=...) at
<...>/src/gcc/gcc/hash-traits.h:255
#4 hashtab_entry_note_pointers
(obj=, h=0x210d5960,
op=0x8d75e0 , cookie=0x1cf0fab0)
at <...>/src/gcc/gcc/hash-table.h:1181
#5 0x008d7d70 in gt_pch_save (f=) at
<...>/src/gcc/gcc/ggc-common.c:549
#6 0x006b72d8 in c_common_write_pch () at
<...>/src/gcc/gcc/c-family/c-pch.c:177
#7 0x004ce405 in c_parse_final_cleanups () at
<...>/src/gcc/gcc/cp/decl2.c:4911
#8 0x00bc34a2 in compile_file () at <...>/src/gcc/gcc/toplev.c:457
#9 0x01c8ff38 in do_compile () at <...>/src/gcc/gcc/toplev.c:2193
#10 toplev::main (this=this@entry=0x1cf0fe0e, argc=,
argc@entry=19, argv=,
argv@entry=0x1f7425b0) at <...>/src/gcc/gcc/toplev.c:2332
#11 0x01df7107 in main (argc=19, argv=0x1f7425b0) at
<...>/src/gcc/gcc/main.c:39
(gdb) print *((hash_table*)0x210d5960)
$1 = {m_entries = 0x210ea800, m_size = 127, m_n_elements = 1, m_n_deleted = 0,
m_searches = 1, m_collisions = 0,
m_size_prime_index = 4, m_ggc = true, m_sanitize_eq_and_hash = true, static
m_gather_mem_stats = false}
(gdb) print *((hash_table*)0x210d5960)->m_entries@127
$2 = {{loc = 0, uid = 0, var = 0x0} , {loc = 10262528, uid =
4294967295, var = 0x210eb2d0}, {
loc = 0, uid = 0, var = 0x0} }
(gdb) call expand_location (10262528)
$3 = {file = 0x1cf91790 "pch.hpp", line = 7, column = 83, data = 0x0, sysp =
false}
I noticed that on a few times `expand_location' displayed incorrect line or
column information for the given input location -- so, the real issue might be
buried quite deep. (I was using an older GDB9, so it might an issue, too.)
I used this to probe the problematic warnings. I took the list from
documentation, I presume it should be pretty complete.
$ for flag in -Waddress -Warray-bounds=1 -Wbool-compare -Wbool-operation
-Wc++11-compat -Wc++14-compat -Wcatch-value -Wchar-subsc
[Bug c++/98343] [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98343 --- Comment #3 from Pekka S --- Hi. Thanks. Applied the patch to the latest trunk, built on x86_64-linux-gnu and tested that it indeed fixes both of these test cases. Did not try on x86_64-w64-mingw32 yet. I presume it will work just fine.
[Bug c++/98343] [11 Regression] ICE in in relocate_ptrs, at ggc-common.c:363 [PCH and C++20 std::source_location?]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98343 --- Comment #4 from Pekka S --- And indeed the patch works on x86_64-w64-mingw32, too.
[Bug libstdc++/98370] New: libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98370 Bug ID: 98370 Summary: libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int' Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Target: aarch64-*-elf Hi. Using GCC 11.0.0 20201218. libstdc++-v3/src/c++17/floating_to_chars.cc: 978 const int whole_digits = max(mantissa_length + fd.exponent, 1); `mantissa_length' is `int' while `fd.exponent' is `int32_t'. If targetting e.g. AArch64 ILP32 `__INT32_TYPE__' is `long int' and this causes failure with `max(const _Tp&, const _Tp&)'. There appears to be no other problematic locations for AArch64 ILP32. <...>libstdc++-v3/src/c++17/floating_to_chars.cc: In instantiation of 'std::to_chars_result std::__floating_to_chars_shortest(char*, char*, T, std::chars_format) [with T = float]': <...>libstdc++-v3/src/c++17/floating_to_chars.cc:1484:73: required from here <...>libstdc++-v3/src/c++17/floating_to_chars.cc:978:37: error: no matching function for call to 'max(long int, int)' 978 | const int whole_digits = max(mantissa_length + fd.exponent, 1); | ~~~^~ In file included from <...>libstdc++-v3/include/bits/specfun.h:45, from <...>libstdc++-v3/include/cmath:1927, from <...>libstdc++-v3/src/c++17/floating_to_chars.cc:33: <...>/libstdc++-v3/include/bits/stl_algobase.h:254:5: note: candidate: 'template constexpr const _Tp& std::max(const _Tp&, const _Tp&)' 254 | max(const _Tp& __a, const _Tp& __b) | ^~~
[Bug c/98487] New: ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X attribute syntax, gnu::format and -Wsuggest-attribute=format]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487
Bug ID: 98487
Summary: ICE: tree check: expected identifier_node, have
tree_list in is_attribute_p, at attribs.h:155 [C2X
attribute syntax, gnu::format and
-Wsuggest-attribute=format]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Created attachment 49862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49862&action=edit
Triggers the ICE.
Hi.
Combining C2X attribute syntax ``[[]]'', gnu::format and
-Wsuggest-attribute=format seems to ICE.
This problem does not occur if a) ``__attribute__'' syntax is used instead, b)
-Wsuggest-attribute=format is not used. Does not happen when processing
function declarations or if the corresponding library call is not present.
Only ``format(printf, ...)'' and ``format(scanf, ...)'' seem to be affected.
Attached test case. Using GCC 11.0.0 20201231, aarch64-*-* on
x86_64-w64-mingw32 but I presume this is not host or target related.
Given e.g. PR90953 and PR94733 I presume the problematic line is at:
gcc/c-family/c-format.c:1216:
1216 if (is_attribute_p ("format", TREE_PURPOSE (c))
and it should use` get_attribute_name' instead. Attached a patch that does
just that. Seems to fix the problem, but I'm no expert on GCC internals.
$ cat attribute__format.c [excerpt]
#define ATTR(...) [[gnu::__VA_ARGS__]]
// ...
ATTR(__format__(__printf__, 1, 2))
void
do_printf(const char * const a0, ...) { /* ... */ }
$ gcc -c -std=c2x -Wall -Wextra -Wpedantic -Wsuggest-attribute=format
attribute__format.c
attribute__format.c: In function 'do_printf':
attribute__format.c:17:3: internal compiler error: tree check: expected
identifier_node, have tree_list in is_attribute_p, at attribs.h:155
17 | vprintf(a0, ap);
| ^~~
$ gcc -c -std=c2x -Wall -Wextra -Wpedantic -Wsuggest-attribute=format -wrapper
gdb,--args
(gdb) b internal_error
(gdb) run
Thread 1 hit Breakpoint 1, internal_error (
gmsgid=0x1cc3f90 <(anonymous namespace)::pass_data_vrp+2000> "tree check:
%s, have %s in %s, at %s:%d")
at <...>/gcc/gcc/diagnostic.c:1764
(gdb) bt
#0 internal_error (
gmsgid=0x1cc3f90 <(anonymous namespace)::pass_data_vrp+2000> "tree check:
%s, have %s in %s, at %s:%d")
at <...>/gcc/gcc/diagnostic.c:1764
#1 0x01a9adf2 in tree_check_failed (node=,
file=0x1bc8580
"<...>/gcc/gcc/attribs.h",
line=, function=0x1bc856d
"is_attribute_p")
at <...>/gcc/gcc/tree.c:13438
#2 0x01921e1a in tree_check (__c=, __g=,
__l=,
__f=, __t=) at <...>/gcc/gcc/tree.h:3594
#3 is_attribute_p (ident=0x1cc3f90 <(anonymous
namespace)::pass_data_vrp+2000>,
attr_name=0x1bc90fd "format")
at <...>/gcc/gcc/attribs.h:155
#4 0x019228d6 in is_attribute_p (attr_name=0x1bc90fd
"format",
ident=) at <...>/gcc/gcc/tree.h:3452
#5 check_function_format (fntype=fntype@entry=0x1eea39d8, attrs=, nargs=nargs@entry=2,
argarray=argarray@entry=0x1edf9e40, arglocs=arglocs@entry=0x1ad0e878)
at <...>/gcc/gcc/c-family/c-format.c:1216
#6 0x004cbea6 in check_function_arguments (loc=loc@entry=34268454,
fndecl=fndecl@entry=0x1ec0b900,
fntype=fntype@entry=0x1eea39d8, nargs=, nargs@entry=2,
argarray=argarray@entry=0x1edf9e40,
arglocs=arglocs@entry=0x1ad0e878) at <...>/gcc/gcc/tree.h:3718
#7 0x0044c701 in build_function_call_vec (loc=,
loc@entry=34268454, arg_loc=arg_loc@entry=...,
function=, function@entry=0x1ec0b900, params=, origtypes=,
origtypes@entry=0x1eeddb90, orig_fundecl=0x1ec0b900,
orig_fundecl@entry=0x0)
at <...>/gcc/gcc/c/c-typeck.c:3144
#8 0x0044d4fa in c_build_function_call_vec (loc=loc@entry=34268454,
arg_loc=...,
function=function@entry=0x1ec0b900, params=,
params@entry=0x1edf9e38, origtypes=0x1eeddb90)
at <...>/gcc/gcc/c/c-typeck.c:3210
#9 0x0046ea76 in c_parser_postfix_expression_after_primary
(parser=parser@entry=0x1ead4240,
expr_loc=expr_loc@entry=34268454, expr=...) at
<...>/gcc/gcc/c/c-parser.c:10469
#10 0x00465724 in c_parser_postfix_expression (parser=,
parser@entry=0x1ead4240)
at <...>/gcc/gcc/../libcpp/include/line-map.h:577
#11 0x00469fdb in c_parser_unary_expression
(parser=parser@entry=0x1ead4240)
at <...>/gcc/gcc/c/c-parser.c:8230
#12 0x0046ba20 in c_parser_cast_expression
(parser=parser@entry=0x1ead4240, after=after@entry=0x0)
at <...>/gcc/gcc/c/c-parser.c:8072
#13 0x0046bcf6 in c_parser_binary_expression
(parser=parser@entry=0x1ead4240, after=0x0, omp_atomic_lhs=0x0)
at <...>/gcc/gcc/c/c-parser.c:7875
#14 0x0046d09e in c_parser_conditional_expression
(parser=parser@entry=0x1ead4240, after=,
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X attribute syntax, gnu::format and -Wsuggest-attribute=format]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 --- Comment #1 from Pekka S --- Created attachment 49863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49863&action=edit Possible patch Uses get_attribute_name instead of TREE_PURPOSE.
[Bug c/108395] New: [C2x] Bogus -Wunused-but-set-variable when returning constexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108395
Bug ID: 108395
Summary: [C2x] Bogus -Wunused-but-set-variable when returning
constexpr variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Hi.
It appears if constexpr variable, declared at block scope, is used verbatim as
a return value GCC emits a bogus -Wunused-but-set-variable.
Using version `13.0.0 20230113 (experimental)'.
# echo 'int f() { constexpr int v = 0; return v; }' | gcc -c -xc -std=c2x -Wall
-Wextra -
: In function 'f':
:1:25: warning: variable 'v' set but not used
[-Wunused-but-set-variable]
As a workaround any operation on v (cast, effectively-no-op arithmetics etc.)
or maybe_unused attribute (or file scope) can be used.
[Bug c/108520] New: [C2x] ICE in nonnull_arg_p, at tree.cc:14372 with -O1 and above (gnu::assume)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108520
Bug ID: 108520
Summary: [C2x] ICE in nonnull_arg_p, at tree.cc:14372 with -O1
and above (gnu::assume)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Hi.
Consider the following testcase. The important aspects are i) optimized, ii)
array of structures containing multiple elements, iii) assume.
Using 13.0.1 20230124 (experimental).
# cat assume.c
static
void f0() { }
[[ gnu::nonnull(1) ]]
void f1(void *)
{
const struct { void (*f)(); } af[] = {
{ f0 } , { f0 } , { f0 }
};
for (__typeof__(af[0]) * it = af, * const end = af + sizeof(af) /
sizeof(af[0]); it != end; ++it)
{
[[ gnu::assume (it->f) ]];
it->f();
}
}
# gcc -c -std=gnu2x -Wall -Wextra -O1 assume.c
during GIMPLE pass: ethread
assume.c: In function 'f1':
assume.c:16:3: internal compiler error: in nonnull_arg_p, at tree.cc:14372
---
(gdb) bt
#0 in fancy_abort(char const*, int, char const*) ()
#1 in nonnull_arg_p(tree_node const*) [clone .cold] ()
#2 in get_range_global (r=..., name=)
at <...>/src/gcc/gcc/value-query.cc:330
#3 in global_range_query::range_of_expr (this=,
r=..., expr=,
stmt=) at <...>/src/gcc/gcc/value-query.cc:406
#4 in gimple_infer_range::check_assume_func (this=,
call=)
at <...>/src/gcc/gcc/gimple-range-infer.cc:87
#5 in gimple_infer_range::gimple_infer_range (this=,
s=)
at <...>/src/gcc/gcc/gimple-range-infer.cc:166
#6 in infer_range_manager::register_all_uses (this=,
name=)
at <...>/src/gcc/gcc/gimple-range-infer.cc:374
#7 in infer_range_manager::has_range_p (this=,
name=,
bb=) at <...>/src/gcc/gcc/gimple-range-infer.cc:273
#8 in infer_range_manager::maybe_adjust_range (this=,
r=..., name=,
bb=) at <...>/src/gcc/gcc/gimple-range-infer.cc:290
#9 in path_range_query::adjust_for_non_null_uses (this=, bb=)
at <...>/src/gcc/gcc/gimple-range-path.cc:502
#10 in path_range_query::compute_ranges (this=,
dependencies=)
at <...>/src/gcc/gcc/gimple-range-path.cc:623
#11 in back_threader::find_taken_edge_cond (this=,
path=..., cond=)
at <...>/src/gcc/gcc/bitmap.h:955
#12 in back_threader::maybe_register_path (this=,
profit=...)
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:248
#13 in back_threader::find_paths_to_names (this=,
bb=,
interesting=, overall_paths=,
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:371
#14 in back_threader::find_paths_to_names (this=,
bb=,
interesting=, overall_paths=,
at <...>/src/gcc/gcc/bitmap.h:955
#15 in back_threader::maybe_thread_block (this=,
bb=)
at <...>/src/gcc/gcc/bitmap.h:955
#16 in back_threader::thread_blocks (this=)
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:975
#17 in pass_thread_jumps_full::execute (this=,
fun=)
at <...>/src/gcc/gcc/tree-ssa-threadbackward.cc:1105
#18 in execute_one_pass (pass=)
at <...>/src/gcc/gcc/passes.cc:2644
#19 in execute_pass_list_1 (pass=)
at <...>/src/gcc/gcc/passes.cc:2753
#20 in execute_pass_list_1 (pass=)
at <...>/src/gcc/gcc/passes.cc:2754
#21 in execute_pass_list (fn=, pass=)
at <...>/src/gcc/gcc/passes.cc:2764
#22 in cgraph_node::expand (this=)
at <...>/src/gcc/gcc/context.h:48
#23 in symbol_table::compile (this=)
at <...>/src/gcc/gcc/cgraphunit.cc:2015
#24 in symbol_table::finalize_compilation_unit (this=)
at <...>/src/gcc/gcc/cgraphunit.cc:2302
#25 in compile_file () at <...>/src/gcc/gcc/toplev.cc:471
#26 in toplev::main(int, char**) ()
#27 in main (argc=<...>, argv=<...>) at <...>/src/gcc/gcc/main.cc:39
[Bug c++/61882] attribute weak ignored for function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61882
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #2 from Pekka S ---
This is problem is still present on GCC 13 to a certain degree.
For an example, the following construct is not possible, as `weak_template' is
essentially always considered being present unless using -O0. Note that `weak'
behaves as expected even it is not extern "C".
If weak address is sourced from GOT (PIC/PIE) and the symbol is undefined, the
program will likely crash, as the address is zero (typically optimized as an
unconditional indirect branch).
Purely static builds are affected as well, but as there is no indirect branch,
the non-existing branch is likely replaced by a no-operation during linking and
possibly goes unnoticed for simple constructs like these.
[[gnu::weak]] extern void weak();
template
[[gnu::weak]] extern void weak_template();
void call ()
{
auto f0 = weak;
auto f1 = weak_template;
if (f0) f0();
if (f1) f1(); /* NB: else statement would be always ignored here. */
// indirect_call(f1); /* see below. */
}
It is possible to overcome this issue by not calling the acquired address
directly but passing it first to another function. This helper function must
not be inlined / optimized (which might require additional tricks documented in
the manual and so forth).
[[gnu::noipa]] static void indirect_call (auto f)
{
if (f) f();
}
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #3 from Pekka S ---
Created attachment 52203
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52203&action=edit
Ensure _M_ver and _M_cv/_M_mtx are synchronized
Hi.
I suspect this is not a w64-mingw32 specific error but present on all platforms
that do not define _GLIBCXX_HAVE_PLATFORM_WAIT.
If I have not mistaken the problem lies within __waiter_pool::_M_do_wait and
that _M_ver and _M_cv/_M_mtx are not properly synchronized:
stdlibc++v3/include/bits/atomic_wait.h:
254 void
255 _M_do_wait(const __platform_wait_t* __addr, __platform_wait_t __old)
noexcept
256 {
257 #ifdef _GLIBCXX_HAVE_PLATFORM_WAIT
258 __platform_wait(__addr, __old);
259 #else
260 __platform_wait_t __val;
261 __atomic_load(__addr, &__val, __ATOMIC_RELAXED);
262 if (__val == __old)
263 {
264 lock_guard __l(_M_mtx);
265 _M_cv.wait(_M_mtx);
266 }
267 #endif // __GLIBCXX_HAVE_PLATFORM_WAIT
268 }
In this case _GLIBCXX_HAVE_PLATFORM_WAIT is not defined and __addr will point
to __waiter_pool_base::_M_ver (I do not know why it is called ver). _M_ver is
used to indicate if a thread has been notified. __old is the value of _M_ver
when the conditional wait was entered at __waiter::_M_do_wait_v or
__waiter::_M_do_wait.
(__waiter and __waiter_pool are different classes, __waiter::_M_do_wait calls
__waiter__pool::_M_do_wait unless a predicate on which to wait passes.)
310 if (_M_laundered())
311 {
312 __atomic_fetch_add(_M_addr, 1, __ATOMIC_ACQ_REL);
313 __all = true;
314 }
Each time a thread is notified _M_ver is incremented by one. _M_laundered
simply checks if _M_addr is equal to _M_ver (of __waiter_base::_M_w).
This is where the problem is: A waiting thread might observe a (soon-to-be)
stale value which is equal to __old. This is because between __atomic_load and
_M_cv.wait the value of _M_ver might change. So, in other words,
_M_cv.notify_all (note that notify_one never actually happens since __all is
forced as true) might occur before _M_cv.wait is properly registered and/or
actually waiting.
As __waiter_bool::_M_do_wait can only observe _M_ver (e.g. not a value of
atomic_flag on which the user expects the wait to happen) it must not wait
based on a stale information -- so, it absolutely must not miss any notifies,
or it will not be able to return to __waiter::_M_do_wait which does the
predicate level checking.
My suggestion is that __l(_M_mtx) shall be moved outside the `if (__val ==
__old)' block and _M_ver shall be only modified if the _M_mtx mutex is held.
Since _M_cv.wait(_M_mtx) releases the mutex when the thread is actually waiting
this should "just work".
Attached patch does that and bit more: _M_laundered is moved from
__waiter_base to __waiter_pool_base since it must be able to access _M_mtx.
_M_enter_notify is added along with _M_enter, _M_leave and
__detail::__atomic_load_value helpers. _M_mtx and _M_cv are marked mutable so
that __waiter_pool::_M_do_wait / _M_do_spin can be made const. Instead of
__addr it uses _M_ver (and adds _M_laundered(__addr) assertation) to clearly
communicate that non-_GLIBCXX_HAVE_PLATFORM_WAIT code is specialized. Also,
added const and/or noexcept where due.
[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080 Pekka S changed: What|Removed |Added CC||p...@gcc-bugzilla.mail.kaps ||i.fi --- Comment #3 from Pekka S --- Created attachment 52216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52216&action=edit Fix compile issue with newlib A further improved patch. Simply does an explicit cast following the style of the library; int32_t(64). With the patch compiles for target AArch64 LP64/ILP32, not tested otherwise.
[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 Pekka S changed: What|Removed |Added CC||p...@gcc-bugzilla.mail.kaps ||i.fi --- Comment #7 from Pekka S --- I have a similar cross compiler setup and I'm seeing this exact issue. However, I suspect this is actually due to https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=84401ce5fb4ecab55decb472b168100e7593e01f. Looking at `gcc/build-x86_64-linux-gnu/libiberty/config.log' libiberty/configure uses different compiler/preprocessor for tests; ac_fn_c_try_compile uses `gcc' (i.e. host) but ac_fn_c_try_cpp (via ac_fn_c_check_header_preproc, the one which is used for e.g. process.h probing) uses `x86_64-w64-mingw32-gcc -E' (i.e. target). This can be also seen from the corresponding `gcc/build-x86_64-linux-gnu/libiberty/config.cache' where ac_cv_env_CPP_value and ac_cv_prog_CPP are populated with target preprocessor whereas other are host programs. I presume this shouldn't happen since `gcc/build-x86_64-linux-gnu/libiberty' is being built (its target counterpart `gcc/libiberty' compiles just fine).
[Bug other/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 --- Comment #8 from Pekka S --- Created attachment 51734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51734&action=edit For CPP_FOR_BUILD use $(CC_FOR_BUILD) -E instead of $(CPP). The problem is that when $(CPP) is not defined it is set to $(CC) -E by default (by GNU make). However, CPP_FOR_BUILD shall use CC_FOR_BUILD, not CC.
[Bug libstdc++/103305] Cannot build libstdc++ with newlib on aarch64-none-elf or bfin-elf with new version of newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #14 from Pekka S ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > static const mask blank= space;
>
> We might want to use blank = _ISspace | _ISblank for this last one, but I
> don't really understand what newlib defines those categories as:
>
>
> #define isblank(__c) \
> __extension__ ({ __typeof__ (__c) __x = (__c); \
> (__ctype_lookup(__x)&_B) || (int) (__x) == '\t';})
> (__ctype_lookup(__x)&_ISblank) || (int) (__x) == '\t';})
>
> This definition is weird ... why is '\t' not already handled by _ISblank?
It has been attempted in the past:
https://sourceware.org/legacy-ml/newlib/2009/threads.html#00342
The used 8-bit mask is simply not wide enough to disambiguate all POSIX
character classes; Namely space, blank and print classes are the problematic
ones to distinguish properly. The naming of newlib character classes does not
fully align with POSIX, and this has to do with the restrictions that come from
space concerns and limitations.
Also, libstdc++-v3/config/locale/newlib/ctype_members.cc does not handle blank
class even though newlib supports wctype("blank"). As explained above, in this
case it really doesn't matter, since matching a character to a (true POSIX)
class using a mask bit alone is not possible.
Anyway, I made a similar patch but never got around submitting it. I also used
_ISblank | _ISspace since IMHO it is "less wrong" than _ISspace (or equal to
space) alone and added a note explaining the issue.
(Yes, I was about to repeat the history.)
[Bug other/102408] New: [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102408 Bug ID: 102408 Summary: [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-w64-mingw32 Hi. random() is not available on all platforms (it's XSI), e.g. mingw. I wonder if the simplest thing would be simply to use rand() or std::rand() given that the required random value is quite small? <...>/gcc/omp-oacc-neuter-broadcast.cc: In function 'void oacc_do_neutering(long long unsigned int, long long unsigned int)': <...>/gcc/omp-oacc-neuter-broadcast.cc:1786:23: error: 'random' was not declared in this scope; did you mean 'rand'? 1786 |base = bounds_lo + random () % 512; The problematic commit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2a3f9f6532bb21d8ab6f16fbe9ee603f6b1405f2
[Bug c/107589] New: [C2x] `-Wold-style-declaration' triggers warning on `const auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107589
Bug ID: 107589
Summary: [C2x] `-Wold-style-declaration' triggers warning on
`const auto'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Hi.
`-Wold-style-declaration' currently triggers warning when used with C2x `const
auto' (`auto const' is not affected).
Apparently the standard is a bit vague about this case. Grammar `const auto'
is accepted by LLVM [1]. Also, the corresponding GCC testcases (c2x-auto-1.c
and c2x-auto-2.c) use `const auto' (not `auto const').
Using version `13.0.0 20221109 (experimental)':
# echo 'void f() { const auto x [[maybe_unused]] = 0; }' | gcc -c -xc -std=c2x
-Wold-style-declaration -
: In function 'f':
:1:1: warning: 'auto' is not at beginning of declaration
[-Wold-style-declaration]
[1] https://reviews.llvm.org/D133289
[Bug driver/105568] New: Superfluous --jobserver-auth= check taints further diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105568 Bug ID: 105568 Summary: Superfluous --jobserver-auth= check taints further diagnostics Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Hi. When linking with -flto=jobserver both gcc/gcc.cc and gcc/lto-wrapper.cc check if MAKEFLAGS contains "--jobserver-auth=" and if so attempt to further scrutinize its contents. Unfortunately, detect_jobserver() (at gcc/gcc.cc), which is executed always when linking, silently removes the entire "--jobserver-auth=" (up until next space) shall this scrutinization attempt fail. This makes jobserver_active_p() (at gcc/lto-wrapper.cc) always complain about a missing "--jobserver-auth=". Indeed, this might be now technically true, but it is very confusing and misleading if this was done because detect_jobserver() was not satisfied with the given "--jobserver-auth=". There a many reasons why the given "--jobserver-auth=" might be treated as non-functioning. Either GNU make is using an another jobserver type (named semaphore), the given file descriptors are inaccessible because GNU make and GCC are using different emulation layers (e.g. Mingw and Cygwin) or those simply are indeed not inherited, i.e. user forgot to add `+' to invoking GNU rule. Therefore it might be still necessary to remove the "--jobserver-auth=" but I presume this should done after jobserver_active_p(). Actually, this is already being done, as the entire MAKEFLAGS is emptied unless jobserver logic is enabled.
[Bug lto/106118] New: lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106118 Bug ID: 106118 Summary: lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 53216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53216&action=edit move -pthread from LDFLAGS to AM_LDFLAGS (prior autoreconf) Hi. "lto-plugin: make claim_file_handler thread-safe" [1] uses LDFLAGS="-pthread" at configure.ac. Unfortunately, LDFLAGS is not passed from configure to the Makefile recipe that links liblto_plugin.la. Perhaps just move -pthread to AM_LDFLAGS at Makefile.in? AC_CHECK_HEADER does not use LDFLAGS anyway. It is implicitly used by other checks but I wonder if that just makes things more misleading (a missing pthread library, that is). Also, it seems that pretty much every library has a different way of checking and setting -pthread, -lpthread et. al. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2669cae081c852bc8bde1647d671aa66930cc556
[Bug driver/111014] New: do_spec_1 terminates arguments too eagerly when processing spec function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111014
Bug ID: 111014
Summary: do_spec_1 terminates arguments too eagerly when
processing spec function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Hi.
do_spec_1 always terminates the current argument (via end_going_arg) if
processing a spec function.
6881 if (processing_spec_function)
6882end_going_arg ();
If a spec function returns a non-null string it is expanded using do_spec_1.
7043 funcval = eval_spec_function (func, args, soft_matched_part);
7044 if (funcval != NULL && do_spec_1 (funcval, 0, NULL) < 0)
However, because processing_spec_function is in this case non-zero, there is
always a termination after each nested %-sequence has been processed.
Thus, e.g. "%:version-compare(>= 1.0 -version-compare= %%(do_spec))" and
"%(do_spec)" behave differently if the expanded %-sequences have any trailing
parts:
# cat version_compare_string.spec
*self_spec:
+ --version-compare=1.0 %<-version-compare=*
*do_spec:
-W%{!Werror:no-}error
*cc1_options:
+ %:version-compare(>= 1.0 -version-compare= %%(do_spec)) %(do_spec)
# gcc -c -xc -specs=version_compare_string.spec - < /dev/null
cc1: error: unrecognized command-line option ‘-Wno-’
[...]
In the first case, do_spec is not expanded as "-Wno-error" but as "-Wno-" and
"error". I wonder if this termination is really necessary; the same effect can
be archieved by simply having a whitespace character to follow the spec
function, if concatenation is not to be desired.
[Bug bootstrap/111325] New: config/acx.m4: _FOR_TARGET are not usable at top level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111325 Bug ID: 111325 Summary: config/acx.m4: _FOR_TARGET are not usable at top level Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Hi. `_FOR_TARGET' environment variables are not usable if used at top level configure when build == host and build != target. The problem is that ACX_CHECK_INSTALLED_TARGET_TOOL first checks for . If cache variable `ac_cv_path_' (`VAR'=`_FOR_TARGET') is empty, attempts to use AC_PATH_PROG(VAR, PROG, ...) (defined at lib/autoconf/programs.m4). Unfortunately, AC_PATH_PROG always sets `' to cache variable `ac_cv_path_' (that we know is potentially empty), i.e. `_FOR_TARGET'=`ac_cv_path__FOR_TARGET'. If is not found, the (empty) cache variable is not touched, thus overwriting any user provided `_FOR_TARGET' value. Then, NCN_STRICT_CHECK_TARGET_TOOLS tries to look for . If `_FOR_TARGET' should be used ( is not available), it comes up now empty due to earlier AC_PATH_PROG call. Ultimately, `_FOR_TARGET' is set to a default value for any subsequent configure runs and the user provided value is not picked up. This very likely will not work, given user attempted to override this using `_FOR_TARGET'. config/acx.m4: 340: AC_DEFUN([ACX_CHECK_INSTALLED_TARGET_TOOL], [ ... # NB: Omitted when build == host and build != target. 359: if test -z "$ac_cv_path_$1" && test -n "$gcc_cv_tool_dirs"; then 360: AC_PATH_PROG([$1], [$2], [], [$gcc_cv_tool_dirs]) # NB: $1=$ac_cv_path_$1 if $1 is not found from $gcc_cv_tool_dirs. 361: fi 362: if test -z "$ac_cv_path_$1" ; then 363: NCN_STRICT_CHECK_TARGET_TOOLS([$1], [$2]) 364: else 365: $1=$ac_cv_path_$1 366: fi 367: ]) []dnl # ACX_CHECK_INSTALLED_TARGET_TOOL
[Bug libstdc++/114838] New: __gthread_cond_t et. al. used unconditionally by std_mutex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114838 Bug ID: 114838 Summary: __gthread_cond_t et. al. used unconditionally by std_mutex.h Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Hi. libstdc++/include/bits/std_mutex.h, which is included by , currently uses internal condition variable types __gthread_cond_t et. al. unconditionally. However, these types might be unavailable. For an example, libgcc/config/i386/gthr-win32.h (i.e. Windows targets) only defines these (and __GTHREAD_HAS_COND) if _WIN32_WINNT >= 0x0600. Unfortunately, it is possible, that _WIN32_WINNT is set by default to a lower value. Such is the case with gdb and it uses 0x0501 by default. As of writing, both 0x0501 (Windows XP, EOL 2014) and 0x0600 (Windows Vista, EOL 2017) have been out of support for a number of years. This issue is also present on GCC 13.
[Bug driver/112983] New: gcc.cc: do_spec_1, ICE if missing '}' for %x{...}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112983
Bug ID: 112983
Summary: gcc.cc: do_spec_1, ICE if missing '}' for %x{...}
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Hi.
# cat bracegracemisery.specs
*self_spec: %x{
# gcc --specs=bracegracemisery.specs -E - < /dev/null > /dev/null
Segmentation fault (core dumped)
Happens because when looking for the terminating '}' character the loop
condition does not check if the input buffer runs out.
gcc.cc:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=701f5cdfb59c8f60c9c9bee310ef9de03d1ece27;hb=refs/heads/master#l6683
6683: while (*p++ != '}')
6684: ;
Due to memory layout reproducing this might be difficult (or impossible) or
yield other diagnosted errors (should the out of bounds read contain the
terminating character prior an invalid memory location is accessed).
