Jonathan Wakely [Wed, 4 Sep 2024 20:31:58 +0000 (21:31 +0100)]
libstdc++: Adjust std::span::iterator to be ADL-proof
Because std::span<Incomplete> can be useful, it makes sense to define
std::span<Incomplete>::iterator such that Incomplete is not an
associated class, and so the compiler won't attempt to complete it when
doing ADL for span iterators (including during the definition of
std::span<Incomplete>::const_iterator which checks that iterator
satisfies std::input_or_output_iterator).
We can't make this change for std::vector<Incomplete> because it would
change the mangled name of std::vector<Incomplete>::iterator which would
affect the mangled names of templates and functions written by users.
We can do the same thing for std::basic_stacktrace<Alloc> just so that
Alloc is not an associated class. This is probably less beneficial, as
Alloc can't be incomplete, and using SomeAllocator<Incomplete> as the
allocator parameter doesn't seem useful. But simply making the
stacktrace iterator not use Alloc for ADL lookup seems worthwhile. This
is doable because std::stacktrace is part of C++23 so its ABI isn't
considered stable yet.
libstdc++-v3/ChangeLog:
* include/std/span (span::__iter_tag): Declare nested type.
(span::iterator): Use __iter_tag as second template argument.
* include/std/stacktrace (basic_stacktrace::iterator): Use _Impl
as second template argument.
Jonathan Wakely [Mon, 15 Jan 2024 14:09:21 +0000 (14:09 +0000)]
libstdc++: Enable most of <chrono> for freestanding
This makes durations, time points and calendrical types available for
freestanding. The clocks and time zone utilities are disabled for
freestanding, as they require functions in the hosted lib.
Add support for a new macro _GLIBCXX_NO_FREESTANDING_CHRONO which can be
used to explicitly disable <chrono> for freestanding.
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml (_GLIBCXX_NO_FREESTANDING_CHRONO):
Document macro.
* doc/html/*: Regenerate.
* include/bits/chrono.h [_GLIBCXX_NO_FREESTANDING_CHRONO]:
Only include <bits/require_hosted.h> when this macro is defined.
[_GLIBCXX_HOSTED]: Only define clocks for hosted.
* include/bits/version.def (chrono_udls): Remove hosted=yes.
* include/bits/version.h: Regenerate.
* include/std/chrono [_GLIBCXX_HOSTED]: Only define clocks and
time zone utilities for hosted.
* testsuite/std/time/freestanding.cc: New test.
Jonathan Wakely [Wed, 22 May 2024 15:49:31 +0000 (16:49 +0100)]
libstdc++: Add assertion for valid facet type arguments
LWG 436 confirmed that const-qualified types are valid arguments for
Facet template parameters, but volatile-qualified types are not. Add an
assertion to locale::combine to check for valid types.
libstdc++-v3/ChangeLog:
* include/bits/locale_classes.h (__is_facet): New helper.
* include/bits/locale_classes.tcc (locale::combine): Check that
_Facet type is valid.
Jonathan Wakely [Tue, 9 Jan 2024 23:39:14 +0000 (23:39 +0000)]
libstdc++: Make PSTL algorithms accept C++20 iterators [PR110512]
This is a step towards implementing the C++23 change P2408R5, "Ranges
iterators as inputs to non-Ranges algorithms". C++20 random access
iterators which do not meet the Cpp17RandomAccessIterator requirements
will now be recognized by the PSTL algorithms.
As noted by Patrick, P2408R5 only relaxes the requirements for
non-mutating algorithms, but this relaxes them for all parallel
algorithms. I believe that's OK. A call with a type which previously
didn't compile at all was undefined, so we're allowed to start accepting
those calls if the type satisfies std::random_access_iterator. However,
this also causes a change in behaviour for calls with arguments which
satisfy std::random_access_iterator and meet the Cpp17ForwardIterator
requirements but not the Cpp17RandomAccessIterator requirements. The
algorithms will dispatch to a different implementation now. I believe
that's also OK. The algorithms should give the same results whether
acting on forward iterators or random access iterators, just more
efficiently for the latter.
Additionally, we can optimize the C++17 implementation by using
std::__and_, and use std::__remove_cvref_t and std::__iter_category_t
for readability. This diverges from the upstream PSTL, but since libc++
is no longer using that upstream (so we're the only consumer of this
code) I think it's reasonable to use libstdc++ extensions in localized
places like this. Rebasing this small header on upstream should not be
difficult.
libstdc++-v3/ChangeLog:
PR libstdc++/110512
* include/pstl/execution_impl.h (__are_random_access_iterators):
Recognize C++20 random access iterators, and use more efficient
implementations.
* testsuite/25_algorithms/pstl/110512.cc: New test.
c++, coroutines: Fix handling of bool await_suspend() [PR115905].
As noted in the PR the action of the existing implementation was to
treat a false value from await_suspend () as equivalent to "do not
suspend". Actually it needs to be the equivalent of "resume" - and
we need to restart the dispatcher - since the await_suspend() body
could have already resumed the coroutine.
See also https://github.com/cplusplus/CWG/issues/601 (NAD) for more
discussion.
Since we need to amend the await expansion and the actor build, take
the opportunity to clean up and modernise the code there. Note that
we need to make the jump back to the dispatcher without any scope
exit cleanups (so we have to use the .CO_SUSPN IFN to do this).
PR c++/115905
gcc/cp/ChangeLog:
* coroutines.cc (struct coro_aw_data): Add a member for the
restart dispatch label.
(expand_one_await_expression): Rework to modernise and to
handle the boolean await_suspend() case.
(build_actor_fn): Rework the dispatcher and allow for a jump
back to the dispatcher.
Andrew Pinski [Fri, 13 Sep 2024 17:47:29 +0000 (10:47 -0700)]
phi-opt: Improve heuristics for factoring out with constant (again) [PR116699]
The heuristics for factoring out with a constant checks that the assignment statement
is the last statement of the basic block but sometimes there is a predicate or a nop statement
after the assignment. Rejecting this case does not make sense since both predicates and nop
statements are removed and don't contribute any instructions. So we should skip over them
when checking if the assignment statement was the last statement in the basic block.
phi-opt-factor-1.c's f0 is such an example where it should catch it at phiopt1 (before predicates are removed)
and should happen in a similar way as f1 (which uses a temporary variable rather than return).
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/116699
gcc/ChangeLog:
* tree-ssa-phiopt.cc (factor_out_conditional_operation): Skip over nop/predicates
for seeing the assignment is the last statement.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/phi-opt-factor-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Sat, 14 Sep 2024 03:27:32 +0000 (20:27 -0700)]
vect: release defs of removed statement
While trying to add use of simple_dce_from_worklist
to the vectorizer so we don't need to run a full blown
DCE pass after the vectorizer, there was a crash noticed
due to a ssa name which has a stmt without a bb. This was
due to not calling release_defs after the call to gsi_remove.
Note the code to remove zero use statements should be able to
remove once the use of simple_dce_from_worklist has been added.
But in the meantime, fixing this bug will also improve memory
usage and a few other things which look through all ssa names.
gcc/ChangeLog:
* tree-vect-loop.cc (optimize_mask_stores): Call release_defs
after the call to gsi_remove with last argument of true.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Sat, 14 Sep 2024 19:55:07 +0000 (12:55 -0700)]
testsuite; Fix execute/pr52286.c for 16bit
The code path which was added for 16bit had a broken inline-asm which would
only assign maybe half of the registers for the `long` type to 0.
Adding L to the input operand of the inline-asm fixes the issue by now assigning
the full 32bit value of the input register that would match up with the output register.
Simon Martin [Fri, 13 Sep 2024 14:40:22 +0000 (16:40 +0200)]
c++: Don't mix timevar_start and auto_cond_timevar for TV_NAME_LOOKUP [PR116681]
We currently ICE upon the following testcase when using -ftime-report
=== cut here ===
template < int> using __conditional_t = int;
template < typename _Iter >
concept random_access_iterator = requires { new _Iter; };
template < typename _Iterator >
struct reverse_iterator {
using iterator_concept =
__conditional_t< random_access_iterator< _Iterator>>;
};
void RemoveBottom() {
int iter;
for (reverse_iterator< int > iter;;)
;
}
=== cut here ===
The problem is that qualified_namespace_lookup does a plain start() of
the TV_NAME_LOOKUP timer (that asserts that the timer is not already
started). However this timer has already been cond_start()'d in the call
stack - by pushdecl - so the assert fails.
This patch simply ensures that we always conditionally start this timer
(which is done in all other places that use it).
PR c++/116681
gcc/cp/ChangeLog:
* name-lookup.cc (qualified_namespace_lookup): Use an
auto_cond_timer instead of using timevar_start and timevar_stop.
Jonathan Wakely [Mon, 2 Sep 2024 11:29:04 +0000 (12:29 +0100)]
libstdc++: Refactor loops in std::__platform_semaphore
Refactor the loops to all use the same form, and to not need explicit
'break' or 'continue' jumps. This also avoids a -Wunused-variable
warning with -Wsystem-headers.
Also fix a bug for absolute timeouts specified with a time that isn't
implicitly convertible to __clock_t::time_point, e.g. one with a higher
resolution such as picoseconds. Use chrono::ceil to round up to the next
time point representable by the clock.
libstdc++-v3/ChangeLog:
* include/bits/semaphore_base.h (__platform_semaphore): Refactor
loops to all use similar forms.
(__platform_semaphore::_M_try_acquire_until): Use chrono::ceil
to explicitly convert to __clock_t::time_point.
* testsuite/30_threads/semaphore/try_acquire_for.cc: Check that
using a very high resolution timeout compiles.
* testsuite/30_threads/semaphore/platform_try_acquire_for.cc:
New test.
This adjusts some recently-added tests that won't compile without a
hostedlib libstdc++, missed in the patch that just went in, and also
an old test that I'd missed because it also failed in my baseline.
for gcc/testsuite/ChangeLog
* g++.dg/coroutines/pr108620.C: Skip if !hostedlib because of
unavailable headers.
* g++.dg/other/profile1.C: Likewise.
* g++.dg/ext/pragma-unroll-lambda-lto.C: Skip if !hostedlib
because of unavailable declarations.
The transparent call insns like "*parityhi2.libgcc" output a single
[R]CALL instruction that can be skipped by the skip instructions.
Such insns have attribute "type" of "xcall" and can therefore
be easily recognized. Same applies when "adjust_len" is "call".
gcc/
* config/avr/avr.cc (avr_2word_insn_p): Return true for
transparent calls: When insn attribute "type" is "xcall"
or when "adjust_len" is "call".
Andrew Pinski [Thu, 12 Sep 2024 05:10:53 +0000 (22:10 -0700)]
Fix factor_out_conditional_operation heuristics for constants
While working on a different patch, I noticed the heuristics were not
doing the right thing if there was statements before the NOP/PREDICTs.
(LABELS don't have other statements before them).
AVR: Use avr_byte instead of simplify_gen_subreg (QImode, ...
There are many places where asm output functions have to look at
the constituent bytes and words of the operands. The function of
choice was simplify_gen_subreg (mode, ...) which can be replaced
by the more handy avr_byte (rtx, byte_num).
gcc/
* config/avr/avr.cc: Use functions like avr_byte,
avr_word, avr_[u]int8/16 if convenient.
(avr_uint16): New function.
PR116696 expressed surprise that explicit 'constexpr' was needed on one
function; this was because the function isn't 'inline', and
-fimplicit-constexpr doesn't try to promote non-inline functions. Let's be
more helpful in that situation, and also help trace through functions that
were promoted.
PR c++/116696
gcc/cp/ChangeLog:
* constexpr.cc (explain_invalid_constexpr_fn): When
-fimplicit-constexpr, also explain inline functions, and point out
non-inline functions.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2478.C: Prune extra diagnostic.
* g++.dg/ext/fimplicit-constexpr1.C: New test.
Fortran: Fixes to OpenMP 'interop' directive parsing support
Handle lists as argument to 'fr' and 'attr'; fix parsing corner cases.
Additionally, 'fr' values are now internally stored as integer, permitting
the diagnoses (warning) for values not defined in the OpenMP additional
definitions document.
PR fortran/116661
gcc/fortran/ChangeLog:
* gfortran.h (gfc_omp_namelist): Rename 'init' members for clarity.
* match.cc (gfc_free_omp_namelist): Handle renaming.
* dump-parse-tree.cc (show_omp_namelist): Update for new format
and features.
* openmp.cc (gfc_match_omp_prefer_type): Parse list to 'fr' and 'attr';
store 'fr' values as integer.
(gfc_match_omp_init): Rename variable names.
gcn/mkoffload.cc: Use #embed for including the generated ELF file
gcc/ChangeLog:
* config/gcn/mkoffload.cc (read_file): Remove.
(process_asm): Do not add '#include' to generated C file.
(process_obj): Generate C file that uses #embed and use
__SIZE_TYPE__ and __UINTPTR_TYPE__ instead the #include-defined
size_t and uintptr.
(main): Update call to it; remove no longer needed file I/O.
Another spot where we mark_used a function (in this case ctor or dtor)
even when it is just artificially used inside of thunks (emitted on mingw
with -Os for the testcase).
2024-09-13 Jakub Jelinek <jakub@redhat.com>
PR c++/116678
* optimize.cc: Include decl.h.
(maybe_thunk_body): Temporarily change deprecated_state to
UNAVAILABLE_DEPRECATED_SUPPRESS.
Jakub Jelinek [Fri, 13 Sep 2024 14:11:05 +0000 (16:11 +0200)]
libcpp: Fix up UB in finish_embed
Jonathan reported on IRC that certain unnamed proprietary static analyzer
is unhappy about the new finish_embed function and it is actually right.
On a testcase like:
#embed __FILE__ limit (0) if_empty (0)
params->if_empty.count is 1, limit is 0, so count is 0 (we need just
a single token and one fits into pfile->directive_result). Because
count is 0, we don't allocate toks, so it stays NULL, and then in
1301 if (prefix->count)
1302 {
1303 *tok = *prefix->base_run.base;
1304 tok = toks;
1305 tokenrun *cur_run = &prefix->base_run;
1306 while (cur_run)
1307 {
1308 size_t cnt = (cur_run->next ? cur_run->limit
1309 : prefix->cur_token) - cur_run->base;
1310 cpp_token *t = cur_run->base;
1311 if (cur_run == &prefix->base_run)
1312 {
1313 t++;
1314 cnt--;
1315 }
1316 memcpy (tok, t, cnt * sizeof (cpp_token));
1317 tok += cnt;
1318 cur_run = cur_run->next;
1319 }
1320 }
the *tok = *prefix->base_run.base; assignment will copy the only
token. cur_run is still non-NULL, cnt will be initially 1 and
then decremented to 0, but we invoke UB because we do
memcpy (NULL, cur_run->base + 1, 0 * sizeof (cpp_token));
and then the loop stops because cur_run->next must be NULL.
As we don't really copy anything, toks can be anything non-NULL,
so the following patch fixes that by initializing toks also to
&pfile->directive_result (just something known to be non-NULL).
This should be harmless even for the
#embed __FILE__ limit (1)
case (no non-empty prefix/suffix) where toks isn't allocated
either, but in that case prefix->count will be 0 and in the
1321 for (size_t i = 0; i < limit; ++i)
1322 {
1323 tok->src_loc = params->loc;
1324 tok->type = CPP_NUMBER;
1325 tok->flags = NO_EXPAND;
1326 if (i == 0)
1327 tok->flags |= PREV_WHITE;
1328 tok->val.str.text = s;
1329 tok->val.str.len = sprintf ((char *) s, "%d", buffer[i]);
1330 s += tok->val.str.len + 1;
1331 if (tok == &pfile->directive_result)
1332 tok = toks;
1333 else
1334 tok++;
1335 if (i < limit - 1)
1336 {
1337 tok->src_loc = params->loc;
1338 tok->type = CPP_COMMA;
1339 tok->flags = NO_EXPAND;
1340 tok++;
1341 }
1342 }
loop limit will be 1, so tok is initially &pfile->directive_result,
that is stilled in, then tok = toks; (previously setting tok to NULL,
now to &pfile->directive_result again) and because 0 < 1 - 1 is
false, nothing further will happen and the loop will finish (and as
params->suffix.count will be 0, nothing further will use tok).
2024-09-13 Jakub Jelinek <jakub@redhat.com>
* files.cc (finish_embed): Initialize toks to tok rather
than NULL.
Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
survive register allocation. This in turn leads to wrong register
renaming. Keeping the current approach would mean we need two insns for
*tf_to_fprx2_0 and *tf_to_fprx2_1, respectively. Something along the
lines
and similar for *tf_to_fprx2_1. Note, pre register allocation operand 0
has mode FPRX2 and afterwards DF once subregs have been eliminated.
Since we always copy a whole vector register into a floating-point
register pair, another way to fix this is to merge *tf_to_fprx2_0 and
*tf_to_fprx2_1 into a single insn which means we don't have to use
subregs at all. The downside of this is that the assembler template
contains two instructions, now. The upside is that we don't have to
come up with some artificial insn before RA which might be more
readable/maintainable. That is implemented by this patch.
In commit r11-4872-ge627cda5686592, the output operand specifier %V was
introduced which is used in tf_to_fprx2 only, now. Instead of coming up
with its counterpart %F for floating-point registers, which would also
only be used in tf_to_fprx2, I print the operands directly. This
renders %V unused which is why it is removed by this patch.
Ensure for AQ and AR constraints that the resulting displacement after
adding any positive offset less than the size of the object being
referenced is still valid.
gcc/ChangeLog:
* config/s390/s390.cc (s390_mem_constraint): Check displacement
for AQ and AR constraints.
libstdc++: Do not use use memmove for 1-element ranges [PR108846,PR116471]
This commit ports the fixes already applied by r13-6372-g822a11a1e642e0
to the range-based versions of copy/move algorithms.
When doing so, a further bug (PR116471) was discovered in the
implementation of the range-based algorithms: although the algorithms
are already constrained by the indirectly_copyable/movable concepts,
there was a failing static_assert in the memmove path.
This static_assert checked that iterator's value type was assignable by
using the is_copy_assignable (move) type traits. However, this is a
problem, because the traits are too strict when checking for constness;
a type like
struct S { S& operator=(S &) = default; };
is trivially copyable (and thus could benefit of the memmove path),
but it does not satisfy is_copy_assignable because the operator takes
by non-const reference.
Now, the reason for the check to be there is because a type with
a deleted assignment operator like
struct E { E& operator=(const E&) = delete; };
is still trivially copyable, but not assignable. We don't want
algorithms like std::ranges::copy to compile because they end up
selecting the memmove path, "ignoring" the fact that E isn't even
copy assignable.
But the static_assert isn't needed here any longer: as noted before,
the ranges algorithms already have the appropriate constraints; and
even if they didn't, there's now a non-discarded codepath to deal with
ranges of length 1 where there is an explicit assignment operation.
Therefore, this commit removes it. (In fact, r13-6372-g822a11a1e642e0
removed the same static_assert from the non-ranges algorithms.)
libstdc++-v3/ChangeLog:
PR libstdc++/108846
PR libstdc++/116471
* include/bits/ranges_algobase.h (__assign_one): New helper
function.
(__copy_or_move): Remove a spurious static_assert; use
__assign_one for memcpyable ranges of length 1.
(__copy_or_move_backward): Likewise.
* testsuite/25_algorithms/copy/108846.cc: Extend to range-based
algorithms, and cover both memcpyable and non-memcpyable
cases.
* testsuite/25_algorithms/copy_backward/108846.cc: Likewise.
* testsuite/25_algorithms/copy_n/108846.cc: Likewise.
* testsuite/25_algorithms/move/108846.cc: Likewise.
* testsuite/25_algorithms/move_backward/108846.cc: Likewise.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
16-bit comparisons like R25:24 == -1 are currently performed like
cpi R24, -1
cpc R25, R24
Similar is possible for wider modes. ADIW can be used like SBIW when
the compare code is EQ or NE because such comparisons are just about
(propagating) the Z flag. The patch adds helper functions like avr_byte()
that may be useful in other functions than avr_out_compare().
Use new convenient helper functions that may be useful in
other output functions, too.
The order in which multi-byte EQ and NE comparisons are performing
the byte comparisons does not matter, and there are situations where
using SBIW on the high word can save an instruction.
gcc/
* config/avr/avr.cc (avr_out_compare): Tweak 32-bit EQ and NE
comparisons that can use SBIW for the hi16 part.
Pan Li [Fri, 13 Sep 2024 03:36:40 +0000 (11:36 +0800)]
Match: Remove unnecessary types_match for case 1 of signed SAT_ADD
Given all commutative binary operators requires types matching
for both operands. Remove the types_match check for case 1 of
the signed SAT_ADD, because we have (bit_xor @0 @1), which ensure
the operands have the correct TREE type.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 fully regression test.
gcc/ChangeLog:
* match.pd: Remove the types_match check for signed SAT_ADD
case 1.
Several C++ tests fail with --disable-hosted-libstdcxx, whether
because stdc++exp gets linked in despite not being built, because
standard headers are included but that are unavailable in this mode,
or because headers are (mistakenly?) expected to introduce
declarations such as for abort, malloc, etc, but in this mode they
don't.
This patch introduces an effective target for GCC test, equivalent to
one that's available in the libstdc++-v3 testsuite, and arranges for
all such tests to be skipped when libstdc++-v3 is not hosted.
Co-Authored-By: Olivier Hainque <hainque@adacore.com>
for gcc/ChangeLog
* doc/sourcebuild.texi (hostedlib): New effective target.
Jonathan Wakely [Wed, 11 Sep 2024 09:17:23 +0000 (10:17 +0100)]
libstdc++: Simplify std::launder definition
A single static assert is a much simpler way to implement the
compile-time preconditions on std::launder than an overload set of
deleted functions and function templates. The only difficulty is that
<new> doesn't include <type_traits> so we can't use std::is_function and
std::is_void for the checks. That can be worked around though, by using
the __is_same and __is_function built-ins. If the __is_function built-in
isn't supported then the __builtin_launder built-in will give an error
anyway, since the commit preceding this one.
We can also remove the redundant __cplusplus >= 201703L check around the
definitions of std::launder and the interference constants, which are
already guarded by the appropriate feature test macros.
Jonathan Wakely [Wed, 11 Sep 2024 10:47:44 +0000 (11:47 +0100)]
c++: Make __builtin_launder reject invalid types [PR116673]
The standard says that std::launder is ill-formed for function pointers
and cv void pointers, so there's no reason for __builtin_launder to
accept them. This change allows implementations of std::launder to defer
to the built-in for error checking, although libstdc++ will continue to
diagnose it directly for more user-friendly diagnostics.
PR c++/116673
gcc/cp/ChangeLog:
* semantics.cc (finish_builtin_launder): Diagnose function
pointers and cv void pointers.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/launder2.C: Adjust dg-error strings.
* g++.dg/cpp1z/launder10.C: New test.
Patrick Palka [Thu, 12 Sep 2024 16:45:03 +0000 (12:45 -0400)]
c++: decltype(auto) deduction of statement-expression [PR116418]
r8-7538 for PR84968 made strip_typedefs_expr diagnose STATEMENT_LIST
so that we reject statement-expressions in noexcept-specifiers to
match our behavior in template arguments (which the parser diagnoses
directly).
Later r11-7452 made decltype(auto) deduction canonicalize the expression
(as an implementation detail) which in turn calls strip_typedefs_expr,
and so ever since we inadvertently reject decltype(auto) deduction of a
statement-expression.
This patch just removes the diagnostic in strip_typedefs_expr and instead
treats statement-expressions similar to lambda-expressions. The function
doesn't seem like the right place for such a diagnostic and so it seems
easier to just accept rather than try to reject them in a suitable place.
PR c++/116418
gcc/cp/ChangeLog:
* tree.cc (strip_typedefs_expr) <case STATEMENT_LIST>: Replace
this error path with ...
<case STMT_EXPR>: ... this, returning the original tree.
gcc/testsuite/ChangeLog:
* g++.dg/eh/pr84968.C: No longer expect an ahead of time diagnostic
for the statement-expresssion. Instantiate the template and expect
an incomplete type error instead.
* g++.dg/ext/stmtexpr26.C: New test.
Jakub Jelinek [Thu, 12 Sep 2024 16:22:21 +0000 (18:22 +0200)]
c++: Disable deprecated/unavailable diagnostics when creating thunks for methods with such attributes [PR116636]
On the following testcase, we emit false positive warnings/errors about using
the deprecated or unavailable methods when creating thunks for them, even
when nothing (in the testcase so far) actually used those.
The following patch temporarily disables that diagnostics when creating
the thunks.
2024-09-12 Jakub Jelinek <jakub@redhat.com>
PR c++/116636
* method.cc: Include decl.h.
(use_thunk): Temporarily change deprecated_state to
UNAVAILABLE_DEPRECATED_SUPPRESS.
Jakub Jelinek [Thu, 12 Sep 2024 16:17:05 +0000 (18:17 +0200)]
libcpp, v2: Add support for gnu::base64 #embed parameter
This patch which adds another #embed extension, gnu::base64.
As mentioned in the documentation, this extension is primarily
intended for use by the preprocessor, so that for the larger (say 32+ or
64+ bytes long embeds it doesn't have to emit tens of thousands or
millions of comma separated string literals which would be very expensive
to parse again, but can emit
#embed "." __gnu__::__base64__( \
"Tm9uIGVyYW0gbsOpc2NpdXMsIEJydXRlLCBjdW0sIHF1w6Ygc3VtbWlzIGluZ8OpbmlpcyBleHF1" \
"aXNpdMOhcXVlIGRvY3Ryw61uYSBwaGlsw7Nzb3BoaSBHcsOmY28gc2VybcOzbmUgdHJhY3RhdsOt" \
"c3NlbnQsIGVhIExhdMOtbmlzIGzDrXR0ZXJpcyBtYW5kYXLDqW11cywgZm9yZSB1dCBoaWMgbm9z" \
"dGVyIGxhYm9yIGluIHbDoXJpYXMgcmVwcmVoZW5zacOzbmVzIGluY8O6cnJlcmV0LiBuYW0gcXVp" \
"YsO6c2RhbSwgZXQgaWlzIHF1aWRlbSBub24gw6FkbW9kdW0gaW5kw7NjdGlzLCB0b3R1bSBob2Mg" \
"ZMOtc3BsaWNldCBwaGlsb3NvcGjDoXJpLiBxdWlkYW0gYXV0ZW0gbm9uIHRhbSBpZCByZXByZWjD" \
"qW5kdW50LCBzaSByZW3DrXNzaXVzIGFnw6F0dXIsIHNlZCB0YW50dW0gc3TDumRpdW0gdGFtcXVl" \
"IG11bHRhbSDDs3BlcmFtIHBvbsOpbmRhbSBpbiBlbyBub24gYXJiaXRyw6FudHVyLiBlcnVudCDD" \
"qXRpYW0sIGV0IGlpIHF1aWRlbSBlcnVkw610aSBHcsOmY2lzIGzDrXR0ZXJpcywgY29udGVtbsOp" \
"bnRlcyBMYXTDrW5hcywgcXVpIHNlIGRpY2FudCBpbiBHcsOmY2lzIGxlZ8OpbmRpcyDDs3BlcmFt" \
"IG1hbGxlIGNvbnPDum1lcmUuIHBvc3Ryw6ltbyDDoWxpcXVvcyBmdXTDunJvcyBzw7pzcGljb3Is" \
"IHF1aSBtZSBhZCDDoWxpYXMgbMOtdHRlcmFzIHZvY2VudCwgZ2VudXMgaG9jIHNjcmliw6luZGks" \
"IGV0c2kgc2l0IGVsw6lnYW5zLCBwZXJzw7Nuw6YgdGFtZW4gZXQgZGlnbml0w6F0aXMgZXNzZSBu" \
"ZWdlbnQu")
with the meaning don't actually load some file, instead base64 decode
(RFC4648 with A-Za-z0-9+/ chars and = padding, no newlines in between)
the string and use that as data. This is chosen because it should be
-pedantic-errors clean, fairly cheap to decode and then in optimizing
compiler could be handled as similar binary blob to normal #embed,
while the data isn't left somewhere on the disk, so distcc/ccache etc.
can move the preprocessed source without issues.
It makes no sense to support limit and gnu::offset parameters together
with it IMHO, why would somebody waste providing full data and then
threw some away? prefix/suffix/if_empty are normally supported though,
but not intended to be used by the preprocessor.
This patch adds just the extension side, not the actual emitting of this
during -E or -E -fdirectives-only for now, that will be included in the
upcoming patch.
Compared to the earlier posted version of this extension, this patch
allows the string concatenation in the parameter argument (but still
doesn't allow escapes in the string, why would anyone use them when
only A-Za-z0-9+/= are valid). The patch also adds support for parsing
this even in -fpreprocessed compilation.
2024-09-12 Jakub Jelinek <jakub@redhat.com>
libcpp/
* internal.h (struct cpp_embed_params): Add base64 member.
(_cpp_free_embed_params_tokens): Declare.
* directives.cc (DIRECTIVE_TABLE): Add IN_I flag to T_EMBED.
(save_token_for_embed, _cpp_free_embed_params_tokens): New functions.
(EMBED_PARAMS): Add gnu::base64 entry.
(_cpp_parse_embed_params): Parse gnu::base64 parameter. If
-fpreprocessed without -fdirectives-only, require #embed to have
gnu::base64 parameter. Diagnose conflict between gnu::base64 and
limit or gnu::offset parameters.
(do_embed): Use _cpp_free_embed_params_tokens.
* files.cc (finish_embed, base64_dec_fn): New functions.
(base64_dec): New array.
(B64D0, B64D1, B64D2, B64D3): Define.
(finish_base64_embed): New function.
(_cpp_stack_embed): Use finish_embed. Handle params->base64
using finish_base64_embed.
* macro.cc (builtin_has_embed): Call _cpp_free_embed_params_tokens.
gcc/
* doc/cpp.texi (Binary Resource Inclusion): Document gnu::base64
parameter.
gcc/testsuite/
* c-c++-common/cpp/embed-17.c: New test.
* c-c++-common/cpp/embed-18.c: New test.
* c-c++-common/cpp/embed-19.c: New test.
* c-c++-common/cpp/embed-27.c: New test.
* gcc.dg/cpp/embed-6.c: New test.
* gcc.dg/cpp/embed-7.c: New test.
Jason Merrill [Tue, 27 Aug 2024 17:15:16 +0000 (13:15 -0400)]
libcpp: adjust pedwarn handling
Using cpp_pedwarning (CPP_W_PEDANTIC instead of if (CPP_PEDANTIC cpp_error
lets users suppress these diagnostics with
#pragma GCC diagnostic ignored "-Wpedantic".
This patch changes all instances of the cpp_error (CPP_DL_PEDWARN to
cpp_pedwarning. In cases where the extension appears in a later C++
revision, we now condition the warning on the relevant -Wc++??-extensions
flag instead of -Wpedantic; in such cases often the if (CPP_PEDANTIC) check
is retained to preserve the default non-warning behavior.
I didn't attempt to adjust the warning flags for the C compiler, since it
seems to follow a different system than C++.
The CPP_PEDANTIC check is also kept in _cpp_lex_direct to avoid an ICE in
the self-tests from cb.diagnostics not being initialized.
While working on testcases for these changes I noticed that the c-c++-common
tests are not run with -pedantic-errors by default like the gcc.dg and
g++.dg directories are. And if I specify -pedantic-errors with dg-options,
the default -std= changes from c++?? to gnu++??, which interferes with some
other pedwarns. So two of the tests are C++-only.
libcpp/ChangeLog:
* include/cpplib.h (enum cpp_warning_reason): Add
CPP_W_CXX{14,17,20,23}_EXTENSIONS.
* charset.cc (_cpp_valid_ucn, convert_hex, convert_oct)
(convert_escape, narrow_str_to_charconst): Use cpp_pedwarning
instead of cpp_error for pedwarns.
* directives.cc (directive_diagnostics, _cpp_handle_directive)
(do_line, do_elif): Likewise.
* expr.cc (cpp_classify_number, eval_token): Likewise.
* lex.cc (skip_whitespace, maybe_va_opt_error)
(_cpp_lex_direct): Likewise.
* macro.cc (_cpp_arguments_ok): Likewise.
(replace_args): Use -Wvariadic-macros for pedwarn about
empty macro arguments.
Richard Earnshaw [Thu, 12 Sep 2024 13:24:55 +0000 (14:24 +0100)]
arm: testsuite: make use of -mcpu=unset/-march=unset
This patch makes use of the new ability to unset the CPU or
architecture flags on the command line to enable several more tests on
Arm. It doesn't cover every case and it does enable some tests that
now fail for different reasons when the tests are no-longer skipped;
these were failing anyway for other testsuite configurations, so it's
still an overall improvement.
There's some restructuring required to fully implement this change: we
could previously treat Xscale as an architecture, even though the
option set -mcpu=, we now need to handle this correctly so that we
unset the architecture rather than the CPU. To do this I've added a
new table for these variants and renamed the template functions to use
'cpu' rather than 'arch'. This entailed updating the two XScale
related tests accordingly.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Move xscale to new generator table.
(check_effective_target_arm_arch_FUNC_ok): Add -mcpu=unset to the
list of flags.
(add_options_for_arm_arch_FUNC): Likewise.
(check_effective_target_arm_cpu_FUNC_ok): New function.
(add_options_for_arm_cpu_FUNC): Likewise.
(check_effective_target_arm_cpu_FUNC_link): Likewise.
(check_effective_target_arm_cpu_FUNC_multilib): Likewise.
* gcc.target/arm/g2.c: Update dg directives.
* gcc.target/arm/scd42-2.c: Likewise.
Richard Earnshaw [Wed, 11 Sep 2024 16:06:12 +0000 (17:06 +0100)]
arm: Allow -mcpu and -march options to be unset
The compiler will warn if the architectural specification derived from
a -mcpu option is not the same as that specified by -march. This is
because it was never intended that the two should be used at the same
time: -mcpu=<name> is supposed to be shorthand for -mtune=<name>
-march=arch-of(<name>).
Unfortunately, there are times when the two options passed to the
compiler may come from distinct sources: one example is makefiles
which accumulate options; another is the testsuite itself, when some
tests require a particular architecture setting to be useful - only
running the tests when the compiler/testsuite configuration exactly
matched the requirements would make regression testing especially hard
(we have too many permutations).
So this patch allows a user to cancel any earlier setting of a
particular flag and to make the compiler behave as though it was never
passed. The intended usecase is (sources of options are shown in
parenthesis, but that's just for grouping:
The option processing logic will now simplify this to:
-mcpu=cortex-m33
A useful corollary of this is that
-march=armv7-a -march=unset
will now cause the compiler to behave as though neither the
architecture nor the CPU was ever set and to default back to the
configure-time settings.
gcc/ChangeLog:
* config/arm/arm.h (OPTION_DEFAULT_SPECS): Allow -mcpu and -march
to be unset.
(ARCH_CPU_CLEANUP_SPECS): Likewise
(DRIVER_SELF_SPECS): Add ARCH_CPU_CLEANUP_SPECS
* doc/invoke.texi (arm: -mcpu= and -march=): Document use of 'unset'.
i386: Use offsetable address constraint for double-word memory operands, part 2
Double-word memory operands are accessed as their high and low part, so the
memory location has to be offsettable. Use "o" constraint instead of "m"
for double-word memory operands.
gcc/ChangeLog:
* config/i386/i386.md (*insvti_lowpart_1): Use "o" constraint
instead of "m" for double-word mode memory operands.
Marek Polacek [Tue, 3 Sep 2024 21:01:48 +0000 (17:01 -0400)]
c++: ICE with TTP [PR96097]
We crash when dependent_type_p gets a TEMPLATE_TYPE_PARM outside
a template. That happens here because in
template <template <typename T, typename T::type TT> typename X>
void func() {}
template <typename U, int I>
struct Y {};
void g() { func<Y>(); }
when performing overload resolution for func<Y>() we have to check
if U matches T and I matches TT. So we wind up in
coerce_template_template_parm/PARM_DECL. TREE_TYPE (arg) is int
so we try to substitute TT's type, which is T::type. But we have
nothing to substitute T with. And we call make_typename_type where
ctx is still T, which checks dependent_scope_p and we trip the assert.
It should work to always perform the substitution in a template context.
If the result still contains template parameters, we cannot say if they
match.
PR c++/96097
gcc/cp/ChangeLog:
* pt.cc (coerce_template_template_parm): Increment
processing_template_decl before calling tsubst.
In s390_expand_insv(), if generating code for ICM et al. src is a MEM
and gen_lowpart might force src into a register such that we end up with
patterns which do not match anymore. Use adjust_address() instead in
order to preserve a MEM.
Furthermore, it is not straight forward to enforce a subreg. For
example, in case of a paradoxical subreg, gen_lowpart() may return a
register. In order to compensate this, s390_gen_lowpart_subreg() emits
a reference to a pseudo which does not coincide with its definition
which is wrong. Additionally, if dest is a paradoxical subreg, then do
not try to emit a strict_low_part since it could mean that dest was not
initialized even though this might be fixed up later by init-regs.
Splitter for insn *get_tp_64, *zero_extendhisi2_31,
*zero_extendqisi2_31, *zero_extendqihi2_31 are applied after reload.
Thus, operands[0] is a hard register and gen_lowpart (m, operands[0])
just returns the hard register for mode m which is fine to use as an
argument for strict_low_part, i.e., we do not need to enforce subregs
here since after reload subregs are supposed to be eliminated anyway.
This fixes gcc.dg/torture/pr111821.c.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_gen_lowpart_subreg): Remove.
* config/s390/s390.cc (s390_gen_lowpart_subreg): Remove.
(s390_expand_insv): Use adjust_address() and emit a
strict_low_part only in case of a natural subreg.
* config/s390/s390.md: Use gen_lowpart() instead of
s390_gen_lowpart_subreg().
Richard Biener [Thu, 12 Sep 2024 09:31:59 +0000 (11:31 +0200)]
Abort loop SLP analysis quicker
As we can't cope with removed SLP instances during analysis there's
no point in doing that or even continuing analysis of SLP instances
after a failure. The following makes us abort early.
* tree-vect-slp.cc (vect_slp_analyze_operations): When
doing loop analysis fail after the first failed SLP
instance. Only remove instances when doing BB vectorization.
* tree-vect-loop.cc (vect_analyze_loop_2): Check whether
vect_slp_analyze_operations failed instead of checking
the number of SLP instances remaining.
Jakub Jelinek [Thu, 12 Sep 2024 09:34:06 +0000 (11:34 +0200)]
libcpp: Add support for gnu::offset #embed/__has_embed parameter
The following patch adds on top of the just posted #embed patch
a first extension, gnu::offset which allows to seek in the data
file (for seekable files, otherwise read and throw away).
I think this is useful e.g. when some binary data start with
some well known header which shouldn't be included in the data etc.
2024-09-12 Jakub Jelinek <jakub@redhat.com>
libcpp/
* internal.h (struct cpp_embed_params): Add offset member.
* directives.cc (EMBED_PARAMS): Add gnu::offset entry.
(enum embed_param_kind): Add NUM_EMBED_STD_PARAMS.
(_cpp_parse_embed_params): Use NUM_EMBED_STD_PARAMS rather than
NUM_EMBED_PARAMS when parsing standard parameters. Parse gnu::offset
parameter.
* files.cc (struct _cpp_file): Add offset member.
(_cpp_stack_embed): Handle params->offset.
gcc/
* doc/cpp.texi (Binary Resource Inclusion): Document gnu::offset
#embed parameter.
gcc/testsuite/
* c-c++-common/cpp/embed-15.c: New test.
* c-c++-common/cpp/embed-16.c: New test.
* gcc.dg/cpp/embed-5.c: New test.
Jakub Jelinek [Thu, 12 Sep 2024 09:15:38 +0000 (11:15 +0200)]
libcpp, c-family: Add (dumb) C23 N3017 #embed support [PR105863]
The following patch implements the C23 N3017 "#embed - a scannable,
tooling-friendly binary resource inclusion mechanism" paper.
The implementation is intentionally dumb, in that it doesn't significantly
speed up compilation of larger initializers and doesn't make it possible
to use huge #embeds (like several gigabytes large, that is compile time
and memory still infeasible).
There are 2 reasons for this. One is that I think like it is implemented
now in the patch is how we should use it for the smaller #embed sizes,
dunno with which boundary, whether 32 bytes or 64 or something like that,
certainly handling the single byte cases which is something that can appear
anywhere in the source where constant integer literal can appear is
desirable and I think for a few bytes it isn't worth it to come up with
something smarter and users would like to e.g. see it in -E readably as
well (perhaps the slow vs. fast boundary should be determined by command
line option). And the other one is to be able to more easily find
regressions in behavior caused by the optimizations, so we have something
to get back in git to compare against.
I'm definitely willing to work on the optimizations (likely introduce a new
CPP_* token type to refer to a range of libcpp owned memory (start + size)
and similarly some tree which can do the same, and can be at any time e.g.
split into 2 subparts + say INTEGER_CST in between if needed say for
const unsigned char d[] = {
#embed "2GB.dat" prefix (0, 0, ) suffix (, [0x40000000] = 42)
}; still without having to copy around huge amounts of data; STRING_CST
owns the memory it points to and can be only 2GB in size), but would
like to do that incrementally.
And would like to first include some extensions also not included in
this patch, like gnu::offset (off) parameter to allow to skip certain
constant amount of bytes at the start of the files, plus
gnu::base64 ("base64_encoded_data") parameter to add something which can
store more efficiently large amounts of the #embed data in preprocessed
source.
I've been cross-checking all the tests also against the LLVM implementation
https://github.com/llvm/llvm-project/pull/68620
which has been for a few hours even committed to LLVM trunk but reverted
afterwards. LLVM now has the support committed and I admit I haven't
rechecked whether the behavior on the below mentioned spots have been fixed
in it already or not yet.
The patch uses --embed-dir= option that clang plans to add above and doesn't
use other variants on the search directories yet, plus there are no
default directories at least for the time being where to search for embed
files. So, #embed "..." works if it is found in the same directory (or
relative to the current file's directory) and #embed "/..." or #embed </...>
work always, but relative #embed <...> doesn't unless at least one
--embed-dir= is specified. There is no reason to differentiate between
system and non-system directories, so we don't need -isystem like
counterpart, perhaps -iquote like counterpart could be useful in the future,
dunno what else. It has --embed-directory=dir and --embed-directory dir
as aliases.
There are some differences beyond clang ICEs, so I'd like to point them out
to make sure there is agreement on the choices in the patch. They are also
mentioned in the comments of the llvm pull request.
The most important is that the GCC patch (as well as the original thephd.dev
LLVM branch on godbolt) expands #embed (or acts as if it is expanded) into
a mere sequence of numbers like 123,2,35,26 rather then what clang
effectively treats as (unsigned char)123,(unsigned char)2,(unsigned
char)35,(unsigned char)26 but only does that when using integrated
preprocessor, not when using -save-temps where it acts as GCC.
JeanHeyd as the original author agrees that is how it is currently worded in
C23.
Another difference (not tested in the testsuite, not sure how to check for
effective target /dev/urandom nor am sure it is desirable to check that
during testsuite) is how to treat character devices, named pipes etc.
(block devices are errored on). The original paper uses /dev/urandom
in various examples and seems to assume that unlike regular files the
devices aren't really cached, so
#embed </dev/urandom> limit(1) prefix(int a = ) suffix(;)
#embed </dev/urandom> limit(1) prefix(int b = ) suffix(;)
usually results in a != b. That is what the godbolt thephd.dev branch
implements too and what this patch does as well, but clang actually seems
to just go from st.st_size == 0, ergo it must be zero-sized resource and
so just copies over if_empty if present. It is really questionable
what to do about the character devices/named pipes with __has_embed, for
regular files the patch doesn't read anything from them, relies on
st.st_size + limit for whether it is empty or non-empty. But I don't know
of a way to check if read on say a character device would read anything
or not (the </dev/null> limit (1) vs. </dev/zero> limit (1) cases), and
if we read something, that would be better cached for later because
#embed later if it reads again could read no further data even when it
first read something. So, the patch currently for __has_embed just
always returns 2 on the non-regular files, like the thephd.dev
branch does as well and like the clang pull request as well.
A question is also what to do for gnu::offset on the non-regular files
even for #embed, those aren't seekable and do we want to just read and throw
away the offset bytes each time we see it used?
clang also chokes on the
#if __has_embed (__FILE__ __limit__ (1) __prefix__ () suffix (1 / 0) \
__if_empty__ ((({{[0[0{0{0(0(0)1)1}1}]]}})))) != __STDC_EMBED_FOUND__
#error "__has_embed fail"
#endif
in embed-1.c, but thephd.dev branch accepts it and I don't see why
it shouldn't, (({{[0[0{0{0(0(0)1)1}1}]]}}))) is a balanced token
sequence and the file isn't empty, so it should just be parsed and
discarded.
clang also IMHO mishandles
const unsigned char w[] = {
#embed __FILE__ prefix([0] = 42, [15] =) limit(32)
};
but again only without -save-temps, seems like it
treats it as
[0] = 42, [15] = (99,111,110,115,116,32,117,110,115,105,103,110,101,100,
32,99,104,97,114,32,119,91,93,32,61,32,123,10,35,101,109,98)
rather than
[0] = 42, [15] = 99,111,110,115,116,32,117,110,115,105,103,110,101,100,
32,99,104,97,114,32,119,91,93,32,61,32,123,10,35,101,109,98
and warns on it for -Wunused-value and just compiles it as
[0] = 42, [15] = 98
And also
void foo (int, int, int, int);
void bar (void) { foo (
#embed __FILE__ limit (4) prefix (172 + ) suffix (+ 2)
); }
is treated as
172 + (118, 111, 105, 100) + 2
rather than
172 + 118, 111, 105, 100 + 2
which clang -save-temps or GCC treats it like, so results
in just one argument passed rather than 4.
if (!strstr ((const char *) magna_carta, "imprisonétur")) abort ();
in the testcase fails as well, but in that case calling it in gdb succeeds:
p ((char *(*)(char *, char *))__strstr_sse2) (magna_carta, "imprisonétur")
$2 = 0x555555558d3c <magna_carta+11564> "imprisonétur aut disseisiátur"...
so I guess they are just trying to constant evaluate strstr and do it
incorrectly.
They started with making the optimizations together in the initial patch
set, so they don't have the luxury to compare if it is just because of
the optimization they are trying to do or because that is how the
feature works for them. At least unless they use -save-temps for now.
There is also different behavior between clang and gcc on -M or other
dependency generating options. Seems clang includes the __has_embed
searched files in dependencies, while my patch doesn't. But so does
clang for __has_include and GCC doesn't. Emitting a hard dependency
on some header just because there was __has_include/__has_embed for it
seems wrong to me, because (at least when properly written) the source
likely doesn't mind if the file is missing, it will do something else,
so a hard error from make because of it doesn't seem right. Does
make have some weaker dependencies, such that if some file can be remade
it is but if it doesn't exist, it isn't fatal?
I wonder whether #embed <non-existent-file> really needs to be fatal
or whether we could simply after diagnosing it pretend the file exists
and is empty. For #include I think fatal errors make tons of sense,
but perhaps for #embed which is more localized we'd get better error
reporting if we didn't bail out immediately. Note, both GCC and clang
currently treat those as fatal errors.
clang also added -dE option which with -E instead of preprocessing
the #embed directives keeps them as is, but the preprocessed source
then isn't self-contained. That option looks more harmful than useful to
me.
Also, it isn't clear to me from C23 whether it is possible to have
__has_include/__has_c_attribute/__has_embed expressions inside of
the limit #embed/__has_embed argument.
6.10.3.2/2 says that defined should not appear there (and the patch
diagnoses it and testsuite tests), but for __has_include/__has_embed
etc. 6.10.1/11 says:
"The identifiers __has_include, __has_embed, and __has_c_attribute
shall not appear in any context not mentioned in this subclause."
If that subclause in that case means 6.10.1, then it presumably shouldn't
appear in #embed in 6.10.3, but __has_embed is in 6.10.1...
But 6.10.3.2/3 says that it should be parsed according to the 6.10.1
rules. Haven't included tests like
#if __has_embed (__FILE__ limit (__has_embed (__FILE__ limit (1))))
or
#embed __FILE__ limit (__has_include (__FILE__))
into the testsuite because of the doubts but I think the patch should
handle those right now.
The reason I've used Magna Carta text in some of the testcases is that
I hope it shouldn't be copyrighted after the centuries and I'd strongly
prefer not to have binary blobs in git after the xz backdoor lesson
and wanted something larger which doesn't change all the time.
Oh, BTW, I see in C23 draft 6.10.3.2 in Example 4
if (f_source == NULL);
return 1;
(note the spurious semicolon after closing paren), has that been fixed
already?
Like the thephd.dev and clang implementations, the patch always macro
expands the whole #embed and __has_embed directives except for the
embed keyword. That is most likely not what C23 says, my limited
understanding right now is that in #embed one needs to parse the whole
directive line with macro expansion disabled and check if it satisfies the
grammar, if not, the whole directive is macro expanded, if yes, only
the limit parameter argument is macro expanded and the prefix/suffix/if_empty
arguments are maybe macro expanded when actually used (and not at all if
unused). And I think __has_embed macro expansion has conflicting rules.
2024-09-12 Jakub Jelinek <jakub@redhat.com>
PR c/105863
libcpp/
* include/cpplib.h: Implement C23 N3017 #embed - a scannable,
tooling-friendly binary resource inclusion mechanism paper.
(struct cpp_options): Add embed member.
(enum cpp_builtin_type): Add BT_HAS_EMBED.
(cpp_set_include_chains): Add another cpp_dir * argument to
the declaration.
* internal.h (enum include_type): Add IT_EMBED.
(struct cpp_reader): Add embed_include member.
(struct cpp_embed_params_tokens): New type.
(struct cpp_embed_params): New type.
(_cpp_get_token_no_padding): Declare.
(enum _cpp_find_file_kind): Add _cpp_FFK_EMBED and _cpp_FFK_HAS_EMBED.
(_cpp_stack_embed): Declare.
(_cpp_parse_expr): Change return type to cpp_num_part instead of
bool, change second argument from bool to const char * and add third
argument.
(_cpp_parse_embed_params): Declare.
* directives.cc (DIRECTIVE_TABLE): Add embed entry.
(end_directive): Don't call skip_rest_of_line for T_EMBED directive.
(_cpp_handle_directive): Return 2 rather than 1 for T_EMBED in
directives-only mode.
(parse_include): Don't Call check_eol for T_EMBED directive.
(skip_balanced_token_seq): New function.
(EMBED_PARAMS): Define.
(enum embed_param_kind): New type.
(embed_params): New variable.
(_cpp_parse_embed_params): New function.
(do_embed): New function.
(do_if): Adjust _cpp_parse_expr caller.
(do_elif): Likewise.
* expr.cc (parse_defined): Diagnose defined in #embed or __has_embed
parameters.
(_cpp_parse_expr): Change return type to cpp_num_part instead of
bool, change second argument from bool to const char * and add third
argument. Adjust function comment. For #embed/__has_embed parameters
add an artificial CPP_OPEN_PAREN. Use the second argument DIR
directly instead of string literals conditional on IS_IF.
For #embed/__has_embed parameter, stop on reaching CPP_CLOSE_PAREN
matching the artificial one. Diagnose negative or too large embed
parameter operands.
(num_binary_op): Use #embed instead of #if for diagnostics if inside
#embed/__has_embed parameter.
(num_div_op): Likewise.
* files.cc (struct _cpp_file): Add limit member and embed bitfield.
(search_cache): Add IS_EMBED argument, formatting fix. Skip over
files with different file->embed from the argument.
(find_file_in_dir): Don't call pch_open_file if file->embed.
(_cpp_find_file): Handle _cpp_FFK_EMBED and _cpp_FFK_HAS_EMBED.
(read_file_guts): Formatting fix.
(has_unique_contents): Ignore file->embed files.
(search_path_head): Handle IT_EMBED type.
(_cpp_stack_embed): New function.
(_cpp_get_file_stat): Formatting fix.
(cpp_set_include_chains): Add embed argument, save it to
pfile->embed_include and compute lens for the chain.
* init.cc (struct lang_flags): Add embed member.
(lang_defaults): Add embed initializers.
(cpp_set_lang): Initialize CPP_OPTION (pfile, embed).
(builtin_array): Add __has_embed entry.
(cpp_init_builtins): Predefine __STDC_EMBED_NOT_FOUND__,
__STDC_EMBED_FOUND__ and __STDC_EMBED_EMPTY__.
* lex.cc (cpp_directive_only_process): Handle #embed.
* macro.cc (cpp_get_token_no_padding): Rename to ...
(_cpp_get_token_no_padding): ... this. No longer static.
(builtin_has_include_1): New function.
(builtin_has_include): Use it. Use _cpp_get_token_no_padding
instead of cpp_get_token_no_padding.
(builtin_has_embed): New function.
(_cpp_builtin_macro_text): Handle BT_HAS_EMBED.
gcc/
* doc/cppdiropts.texi (--embed-dir=): Document.
* doc/cpp.texi (Binary Resource Inclusion): New chapter.
(__has_embed): Document.
* doc/invoke.texi (Directory Options): Mention --embed-dir=.
* gcc.cc (cpp_unique_options): Add %{-embed*}.
* genmatch.cc (main): Adjust cpp_set_include_chains caller.
* incpath.h (enum incpath_kind): Add INC_EMBED.
* incpath.cc (merge_include_chains): Handle INC_EMBED.
(register_include_chains): Adjust cpp_set_include_chains caller.
gcc/c-family/
* c.opt (-embed-dir=): New option.
(-embed-directory): New alias.
(-embed-directory=): New alias.
* c-opts.cc (c_common_handle_option): Handle OPT__embed_dir_.
gcc/testsuite/
* c-c++-common/cpp/embed-1.c: New test.
* c-c++-common/cpp/embed-2.c: New test.
* c-c++-common/cpp/embed-3.c: New test.
* c-c++-common/cpp/embed-4.c: New test.
* c-c++-common/cpp/embed-5.c: New test.
* c-c++-common/cpp/embed-6.c: New test.
* c-c++-common/cpp/embed-7.c: New test.
* c-c++-common/cpp/embed-8.c: New test.
* c-c++-common/cpp/embed-9.c: New test.
* c-c++-common/cpp/embed-10.c: New test.
* c-c++-common/cpp/embed-11.c: New test.
* c-c++-common/cpp/embed-12.c: New test.
* c-c++-common/cpp/embed-13.c: New test.
* c-c++-common/cpp/embed-14.c: New test.
* c-c++-common/cpp/embed-25.c: New test.
* c-c++-common/cpp/embed-26.c: New test.
* c-c++-common/cpp/embed-dir/embed-1.inc: New test.
* c-c++-common/cpp/embed-dir/embed-3.c: New test.
* c-c++-common/cpp/embed-dir/embed-4.c: New test.
* c-c++-common/cpp/embed-dir/magna-carta.txt: New test.
* gcc.dg/cpp/embed-1.c: New test.
* gcc.dg/cpp/embed-2.c: New test.
* gcc.dg/cpp/embed-3.c: New test.
* gcc.dg/cpp/embed-4.c: New test.
* g++.dg/cpp/embed-1.C: New test.
* g++.dg/cpp/embed-2.C: New test.
* g++.dg/cpp/embed-3.C: New test.
Simon Martin [Tue, 10 Sep 2024 20:33:18 +0000 (22:33 +0200)]
c++: Don't ICE to build private access error message [PR116323]
We currently ICE upon the following code while building the "[...] is
private within this context" error message
=== cut here ===
class A { enum Enum{}; };
template<typename E, template<typename> class Alloc>
class B : private Alloc<E>, private A {};
template<typename E, template<typename> class Alloc>
int B<E, Alloc>::foo (Enum m) { return 42; }
=== cut here ===
The problem is that since r11-6880, after detecting that Enum cannot be
accessed in B, enforce_access will access the TYPE_BINFO of all the
bases of B, which ICEs for any that is a BOUND_TEMPLATE_TEMPLATE_PARM.
This patch simply skips such bases.
PR c++/116323
gcc/cp/ChangeLog:
* search.cc (get_parent_with_private_access): Only call access_in_type
for RECORD_OR_UNION_TYPE_P base BINFOs.
Richard Biener [Wed, 11 Sep 2024 12:50:02 +0000 (14:50 +0200)]
Better recover from SLP reassociation fails during discovery
When we decide to not process a association chain of size two and
that would also mismatch with a different chain size on another lane
we shouldn't fail discovery hard at this point. Instead let the
regular discovery figure out matching lanes so the parent can
decide to perform operand swapping or we can split groups at better
points rather than forcefully splitting away the first single lane.
For example on gcc.dg/vect/vect-strided-u8-i8.c we now see two
groups of size 4 feeding the store instead of groups of size 1,
three, two, one and one.
* tree-vect-slp.cc (vect_build_slp_tree_2): On reassociation
chain length mismatch do not fail discovery of the node
but try without re-associating to compute a better matches[].
Provide a reassociation failure hint in the dump.
(vect_slp_analyze_node_operations): Avoid stray failure
dumping.
(vectorizable_slp_permutation_1): Dump the address of the
SLP node representing the permutation.
Bohan Lei [Thu, 12 Sep 2024 02:28:03 +0000 (10:28 +0800)]
RISC-V: Eliminate latter vsetvl when fused
Hi all,
A simple assembly check has been added in this version. Previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662783.html
Thanks,
Bohan
------
The current vsetvl pass eliminates a vsetvl instruction when the previous
info is "available," but does not when "compatible." This can lead to not
only redundancy, but also incorrect behaviors when the previous info happens
to be compatible with a later vector instruction, which ends of using the
vsetvl info that should have been eliminated, as is shown in the testcase.
This patch eliminates the vsetvl when the previous info is "compatible."
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::fuse_local_vsetvl_info):
Delete vsetvl insn when `prev_info` is compatible
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vsetvl_bug-4.c: New test.
In avx512f-mask-type.h, we need SIZE being defined to get
MASK_TYPE defined correctly. Fix those testcases where
SIZE are not defined before the include for avv512f-mask-type.h.
RISC-V: Fix vl_used_by_non_rvv_insn logic of vsetvl pass
This patch fixes a bug in the current vsetvl pass. The current pass uses
`m_vl` to determine whether the dest operand has been used by non-RVV
instructions. However, `m_vl` may have been modified as a result of an
`update_avl` call, and thus would be no longer the dest operand of the
original instruction. This can lead to incorrect vsetvl eliminations, as is
shown in the testcase. In this patch, we create a `dest_vl` variable for
this scenerio.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Use `dest_vl` for dest VL operand
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vsetvl_bug-3.c: New test.
My last fix for this issue (PR c++/114947, r15-810) didn't go far
enough; I had assumed that the issue where we lost track of partial
specialisations we would need to walk again later was limited to
partitions (where we always re-walk all specialisations), but the linked
PR is the same cause but for header units, and it is possible to
construct test cases exposing the same bug just for normal modules.
As such this patch just unconditionally ensures that whenever we modify
DECL_TEMPLATE_SPECIALIZATIONS we also track any partial specialisations
that might have added.
Also clean up a couple of comments and assertions to make expected state
more obvious when processing these specs.
Richard Earnshaw [Wed, 21 Aug 2024 15:15:34 +0000 (16:15 +0100)]
arm: avoid indirect sibcalls when IP is live [PR116597]
On Arm only r0-r3 (the argument registers) and IP are available for
use as an address for an indirect sibcall. But if all the argument
registers are used and IP is clobbered during the epilogue, or is used
to pass closure information, then there is no spare register to hold
the address and we must reject the sibcall.
arm_function_ok_for_sibcall did try to handle this, but it did this by
examining the function declaration. That doesn't work if the function
has no prototype, or if the prototype has variadic arguments: we must,
instead, look at the list of actuals for the call rather than the list
of formals.
The old code also worked by laying out all the arguments and then
trying to add one more integer argument at the end of the list, but
this missed a corner case where a hole had been left in the argument
register list due to argument alignment.
We fix all of this by now scanning the list of actual values to be
passed and then checking if a core register has been assigned to that
argument. If it has, then we record which registers were assigned.
Once done we then look to see if all the argument registers have been
assigned and only block the sibcall if that is the case. This permits
us to sibcall:
int (*d)(int, ...);
int g(void);
int i () { return d(g(), 2LL);}
because r1 remains free (the 2LL argument is passed in {r2,r3}).
gcc/
PR target/116597
* config/arm/arm.cc (arm_function_ok_for_sibcall): Use the list of
actuals for the call, not the list of formals.
gcc/testsuite/
PR target/116597
* gcc.target/arm/pac-sibcall-2.c: New test.
* gcc.target/arm/pac-sibcall-3.c: New test.
Richard Biener [Wed, 11 Sep 2024 11:54:33 +0000 (13:54 +0200)]
tree-optimization/116674 - vectorizable_simd_clone_call and re-analysis
When SLP analysis scraps an instance because it fails to analyze we
can end up calling vectorizable_* in analysis mode on a node that
was analyzed during the analysis of that instance again.
vectorizable_simd_clone_call wasn't expecting that and instead
guarded analysis/transform code on populated data structures.
The following changes it so it survives re-analysis.
PR tree-optimization/116674
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Support
re-analysis.
Alex Coplan [Fri, 2 Aug 2024 08:56:07 +0000 (09:56 +0100)]
libstdc++: Restore unrolling in std::find using pragma [PR116140]
Together with the preparatory compiler patches, this patch restores
unrolling in std::__find_if, but this time relying on the compiler to do
it by using:
#pragma GCC unroll 4
which should restore the majority of the regression relative to the
hand-unrolled version while still being vectorizable with WIP alignment
peeling enhancements.
On Neoverse V1 with LTO, this reduces the regression in xalancbmk (from
SPEC CPU 2017) from 5.8% to 1.7% (restoring ~71% of the lost
performance).
libstdc++-v3/ChangeLog:
PR libstdc++/116140
* include/bits/stl_algobase.h (std::__find_if): Add #pragma to
request GCC to unroll the loop.
Alex Coplan [Sat, 3 Aug 2024 17:02:36 +0000 (17:02 +0000)]
lto: Stream has_unroll flag during LTO [PR116140]
When #pragma GCC unroll is processed in
tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll
field (which is currently streamed out and back in during LTO) but also
the cfun->has_unroll flag.
cfun->has_unroll, however, is not currently streamed during LTO. This
patch fixes that.
Prior to this patch, loops marked with #pragma GCC unroll that would be
unrolled by RTL loop2_unroll in a non-LTO compilation didn't get
unrolled under LTO.
gcc/ChangeLog:
PR libstdc++/116140
* lto-streamer-in.cc (input_struct_function_base): Stream in
fn->has_unroll.
* lto-streamer-out.cc (output_struct_function_base): Stream out
fn->has_unroll.
gcc/testsuite/ChangeLog:
PR libstdc++/116140
* g++.dg/ext/pragma-unroll-lambda-lto.C: New test.
being left behind by the testsuite. This is problematic not just from a
"missing cleanup" POV, but also because it can cause the test to pass
spuriously when the test is re-run wtih an unpatched compiler (without
the bug fix). In the broken case, loop2_unroll isn't run at all, so we
end up scanning the old dumpfile (from the previous test run) and making
the dumpfile scan pass.
Running with `-v -v` in RUNTESTFLAGS we can see the following cleanup
attempt is made:
looking again at the ltrans dump file above we can see this will fail for two
reasons:
- The actual dump file has no {C,exe} extension between the basename and
ltrans0.
- The actual dump file has an additional `.ltrans` component after `.ltrans0`.
This patch therefore relaxes the pattern constructed for cleaning up such
dumpfiles to also match dumpfiles with the above form.
Running the testsuite before/after this patch shows the number of files in
gcc/testsuite (in the build dir) with "ltrans" in the name goes from 1416 to 62
on aarch64.
Alex Coplan [Fri, 2 Aug 2024 08:52:50 +0000 (09:52 +0100)]
c++: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions [PR116140]
For the testcase added with this patch, we would end up losing the:
#pragma GCC unroll 4
and emitting "warning: ignoring loop annotation". That warning comes
from tree-cfg.cc:replace_loop_annotate, and means that we failed to
process the ANNOTATE_EXPR in tree-cfg.cc:replace_loop_annotate_in_block.
That function walks backwards over the GIMPLE in an exiting BB for a
loop, skipping over the final gcond, and looks for any ANNOTATE_EXPRS
immediately preceding the gcond.
The function documents the following pre-condition:
/* [...] We assume that the annotations come immediately before the
condition in BB, if any. */
now looking at the exiting BB of the loop, we have:
and crucially there is an intervening assignment between the gcond and
the preceding .ANNOTATE ifn call. To see where this comes from, we can
look to the IR given by -fdump-tree-original:
if (<<cleanup_point ANNOTATE_EXPR <first != last && !use_find(short
int*)::<lambda(short int)>::operator() (&pred, *first), unroll 4>>>)
goto <D.4518>;
else
goto <D.4516>;
here the problem is that we've wrapped a CLEANUP_POINT_EXPR around the
ANNOTATE_EXPR, meaning the ANNOTATE_EXPR is no longer the outermost
expression in the condition.
The CLEANUP_POINT_EXPR gets added by the following call chain:
this patch chooses to fix the issue by first introducing a new helper
class (annotate_saver) to save and restore outer chains of
ANNOTATE_EXPRs and then using it in maybe_convert_cond.
With this patch, we don't get any such warning and the loop gets unrolled as
expected at -O2.
gcc/cp/ChangeLog:
PR libstdc++/116140
* semantics.cc (anotate_saver): New. Use it ...
(maybe_convert_cond): ... here, to ensure any ANNOTATE_EXPRs
remain the outermost expression(s) of the condition.
gcc/testsuite/ChangeLog:
PR libstdc++/116140
* g++.dg/ext/pragma-unroll-lambda.C: New test.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap tests.
3. The x86 fully regression tests.
gcc/ChangeLog:
* match.pd: Add case 2 for the signed .SAT_ADD consumed by
vect pattern.
* tree-vect-patterns.cc (gimple_signed_integer_sat_add): Add new
matching func decl for signed .SAT_ADD.
(vect_recog_sat_add_pattern): Add signed .SAT_ADD pattern match.
Jonathan Wakely [Tue, 10 Sep 2024 13:36:26 +0000 (14:36 +0100)]
libstdc++: Only use std::ios_base_library_init() for ELF [PR116159]
The undefined std::ios_base_library_init() symbol that is referenced by
<iostream> is only supposed to be used for targets where symbol
versioning is supported.
The mingw-w64 target defaults to --enable-symvers=gnu due to using GNU
ld but doesn't actually support symbol versioning. This means it tries
to emit references to the std::ios_base_library_init() symbol, which
isn't really defined in the library. This causes problems when using lld
to link user binaries.
Disable the undefined symbol reference for non-ELF targets.
libstdc++-v3/ChangeLog:
PR libstdc++/116159
* include/std/iostream (ios_base_library_init): Only define for
ELF targets.
* src/c++98/ios_init.cc (ios_base_library_init): Likewise.
Jonathan Wakely [Tue, 10 Sep 2024 13:25:41 +0000 (14:25 +0100)]
libstdc++: std::string move assignment should not use POCCA trait [PR116641]
The changes to implement LWG 2579 (r10-327-gdb33efde17932f) made
std::string::assign use the propagate_on_container_copy_assignment
(POCCA) trait, for consistency with operator=(const basic_string&).
However, this also unintentionally affected operator=(basic_string&&)
which calls assign(str) to make a deep copy when performing a move is
not possible. The fix is for the move assignment operator to call
_M_assign(str) instead of assign(str), as this just does the deep copy
and doesn't check the POCCA trait first.
The bug only affects the unlikely/useless combination of POCCA==true and
POCMA==false, but we should fix it for correctness anyway. it should
also make move assignment slightly cheaper to compile and execute,
because we skip the extra code in assign(const basic_string&).
libstdc++-v3/ChangeLog:
PR libstdc++/116641
* include/bits/basic_string.h (operator=(basic_string&&)): Call
_M_assign instead of assign.
* testsuite/21_strings/basic_string/allocator/116641.cc: New
test.
Jakub Jelinek [Tue, 10 Sep 2024 16:32:58 +0000 (18:32 +0200)]
c++: Fix get_member_function_from_ptrfunc with -fsanitize=bounds [PR116449]
The following testcase is miscompiled, because
get_member_function_from_ptrfunc
emits something like
(((FUNCTION.__pfn & 1) != 0)
? ptr + FUNCTION.__delta + FUNCTION.__pfn - 1
: FUNCTION.__pfn) (ptr + FUNCTION.__delta, ...)
or so, so FUNCTION tree is used there 5 times. There is
if (TREE_SIDE_EFFECTS (function)) function = save_expr (function);
but in this case function doesn't have side-effects, just nested ARRAY_REFs.
Now, if all the FUNCTION trees would be shared, it would work fine,
FUNCTION is evaluated in the first operand of COND_EXPR; but unfortunately
that isn't the case, both the BIT_AND_EXPR shortening and conversion to
bool done for build_conditional_expr actually unshare_expr that first
expression, but none of the other 4 are unshared. With -fsanitize=bounds,
.UBSAN_BOUNDS calls are added to the ARRAY_REFs and use save_expr to avoid
evaluating the argument multiple times, but because that FUNCTION tree is
first used in the second argument of COND_EXPR (i.e. conditionally), the
SAVE_EXPR initialization is done just there and then the third argument
of COND_EXPR just uses the uninitialized temporary and so does the first
argument computation as well.
The following patch fixes that by doing save_expr even if !TREE_SIDE_EFFECTS,
but to avoid doing that too often only if !nonvirtual and if the expression
isn't a simple decl.
2024-09-10 Jakub Jelinek <jakub@redhat.com>
PR c++/116449
* typeck.cc (get_member_function_from_ptrfunc): Use save_expr
on instance_ptr and function even if it doesn't have side-effects,
as long as it isn't a decl.
Jonathan Wakely [Tue, 10 Sep 2024 15:59:29 +0000 (16:59 +0100)]
libstdc++: Add missing exception specifications in tests
Since r15-3532-g7cebc6384a0ad6 18_support/new_nothrow.cc fails in C++98 mode because G++
diagnoses missing exception specifications for the user-defined
(de)allocation functions. Add throw(std::bad_alloc) and throw() for
C++98 mode.
Similarly, 26_numerics/headers/numeric/synopsis.cc fails in C++20 mode
because the declarations of gcd and lcm are not noexcept.
libstdc++-v3/ChangeLog:
* testsuite/18_support/new_nothrow.cc (THROW_BAD_ALLOC): Define
macro to add exception specifications for C++98 mode.
(NOEXCEPT): Expand to throw() for C++98 mode.
* testsuite/26_numerics/headers/numeric/synopsis.cc (gcd, lcm):
Add noexcept.
Marek Polacek [Thu, 29 Aug 2024 19:13:03 +0000 (15:13 -0400)]
c++: mutable temps in rodata [PR116369]
Here we wrongly mark the reference temporary for g TREE_READONLY,
so it's put in .rodata and so we can't modify its subobject even
when the subobject is marked mutable. This is so since r9-869.
r14-1785 fixed a similar problem, but not in set_up_extended_ref_temp.
PR c++/116369
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Don't mark a temporary
TREE_READONLY if its type is TYPE_HAS_MUTABLE_P.
The patch adds an option -foffload-abi-host-opts, which
is set by host in TARGET_OFFLOAD_OPTIONS, and mkoffload then passes its value
to host_compiler.
Javier Miranda [Mon, 26 Aug 2024 18:56:37 +0000 (18:56 +0000)]
ada: First controlling parameter: report error without Extensions allowed
Enable reporting an error when this new aspect/pragma is set to
True, and the sources are compiled without language extensions
allowed.
gcc/ada/
* sem_ch13.adb (Analyze_One_Aspect): Call
Error_Msg_GNAT_Extension() to report an error when the aspect
First_Controlling_Parameter is set to True and the sources are
compiled without Core_Extensions_ Allowed.
* sem_prag.adb (Pragma_First_Controlling_Parameter): Call
subprogram Error_Msg_GNAT_Extension() to report an error when the
aspect First_Controlling_Parameter is set to True and the sources
are compiled without Core_Extensions_Allowed. Report an error when
the aspect pragma does not confirm an inherited True value.
Viljar Indus [Fri, 30 Aug 2024 11:22:16 +0000 (14:22 +0300)]
ada: Normalize span generation on different platforms
The total number of characters on a source code line
is different on Windows and Linux based systems
(CRLF vs LF endings). Use the last non line change
character to adjust printing the spans that go over
the end of line.
gcc/ada/
* diagnostics-pretty_emitter.adb (Get_Last_Line_Char): New. Get
the last non line change character. Write_Span_Labels use the
adjusted line end pointer to calculate the length of the span.
Piotr Trojanek [Wed, 28 Aug 2024 15:56:06 +0000 (17:56 +0200)]
ada: Evaluate calls to GNAT.Source_Info routines in semantic checking
When semantic checking mode is active, i.e. when switch -gnatc is
present or when the frontend is operating in the GNATprove mode,
we now rewrite calls to GNAT.Source_Info routines in evaluation
and not expansion (which is disabled in these modes).
This is needed to recognize constants initialized with calls to
GNAT.Source_Info as static constants, regardless of expansion being
enabled.
gcc/ada/
* exp_intr.ads, exp_intr.adb (Expand_Source_Info): Move
declaration to package spec.
* sem_eval.adb (Eval_Intrinsic_Call): Evaluate calls to
GNAT.Source_Info where possible.
Andrew Pinski [Mon, 9 Sep 2024 22:34:11 +0000 (15:34 -0700)]
phiopt: Move the common code between pass_phiopt and pass_cselim into a seperate function
When r14-303-gb9fedabe381cce was done, it was missed that some of the common parts could
be done in a template and a lambda could be used. This patch implements that. This new
function can be used later on to implement a simple ifcvt pass.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (execute_over_cond_phis): New template function,
moved the common parts from pass_phiopt::execute/pass_cselim::execute.
(pass_phiopt::execute): Move the functon specific parts of the loop
into an lamdba.
(pass_cselim::execute): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 9 Sep 2024 15:08:37 +0000 (08:08 -0700)]
phiopt: Use gimple_phi_result rather than PHI_RESULT [PR116643]
This converts the uses of PHI_RESULT in phiopt to be gimple_phi_result
instead. Since there was already a mismatch of uses here, it
would be good to use prefered one (gimple_phi_result) instead.
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr59539-1.c --target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr59539-1.c --target_board='unix{-m64\ -march=cascadelake}'"
gcc/ChangeLog:
* config/i386/sse.md (*avx2_pcmp<mode>3_1): Don't force_reg
operands[3] when it's not const0_rtx.
Use a new struct diagnostic_option_id rather than just "int" when
referring to command-line options controlling warnings in the
diagnostic subsystem.
No functional change intended, but better documents the meaning of
the code.
gcc/c-family/ChangeLog:
* c-common.cc (c_option_controlling_cpp_diagnostic): Return
diagnostic_option_id rather than int.
(c_cpp_diagnostic): Update for renaming of
diagnostic_override_option_index to diagnostic_set_option_id.
gcc/c/ChangeLog:
* c-errors.cc (pedwarn_c23): Use "diagnostic_option_id option_id"
rather than "int opt". Update for renaming of diagnostic_info
field.
(pedwarn_c11): Likewise.
(pedwarn_c99): Likewise.
(pedwarn_c90): Likewise.
* c-tree.h (pedwarn_c90): Likewise for decl.
(pedwarn_c99): Likewise.
(pedwarn_c11): Likewise.
(pedwarn_c23): Likewise.
gcc/cp/ChangeLog:
* constexpr.cc (constexpr_error): Update for renaming of
diagnostic_info field.
* cp-tree.h (pedwarn_cxx98): Use "diagnostic_option_id" rather
than "int".
* error.cc (cp_adjust_diagnostic_info): Update for renaming of
diagnostic_info field.
(pedwarn_cxx98): Use "diagnostic_option_id option_id" rather than
"int opt". Update for renaming of diagnostic_info field.
(diagnostic_set_info): Likewise.
gcc/d/ChangeLog:
* d-diagnostic.cc (d_diagnostic_report_diagnostic): Update for
renaming of diagnostic_info field.
gcc/ChangeLog:
* diagnostic-core.h (struct diagnostic_option_id): New.
(warning): Use it rather than "int" for param.
(warning_n): Likewise.
(warning_at): Likewise.
(warning_meta): Likewise.
(pedwarn): Likewise.
(permerror_opt): Likewise.
(emit_diagnostic): Likewise.
(emit_diagnostic_valist): Likewise.
(emit_diagnostic_valist_meta): Likewise.
* diagnostic-format-json.cc
(json_output_format::on_report_diagnostic): Update for renaming of
diagnostic_info field.
* diagnostic-format-sarif.cc (sarif_builder::make_result_object):
Likewise.
(make_reporting_descriptor_object_for_warning): Likewise.
* diagnostic-format-text.cc (print_option_information): Likewise.
* diagnostic-global-context.cc (emit_diagnostic): Use
"diagnostic_option_id option_id" rather than "int opt".
(emit_diagnostic_valist): Likewise.
(emit_diagnostic_valist_meta): Likewise.
(warning): Likewise.
(warning_at): Likewise.
(warning_meta): Likewise.
(warning_n): Likewise.
(pedwarn): Likewise.
(permerror_opt): Likewise.
* diagnostic.cc (diagnostic_set_info_translated): Update for
renaming of diagnostic_info field.
(diagnostic_option_classifier::classify_diagnostic): Use
"diagnostic_option_id option_id" rather than "int opt".
(update_effective_level_from_pragmas): Update for renaming of
diagnostic_info field.
(diagnostic_context::diagnostic_enabled): Likewise.
(diagnostic_context::warning_enabled_at): Use
"diagnostic_option_id option_id" rather than "int opt".
(diagnostic_context::diagnostic_impl): Likewise.
(diagnostic_context::diagnostic_n_impl): Likewise.
* diagnostic.h (diagnostic_info::diagnostic_info): Update for...
(diagnostic_info::option_index): Rename...
(diagnostic_info::option_id): ...to this.
(class diagnostic_option_manager): Use
"diagnostic_option_id option_id" rather than "int opt" for vfuncs.
(diagnostic_option_classifier): Likewise for member funcs.
(diagnostic_classification_change_t::option): Add comment.
(diagnostic_context::warning_enabled_at): Use
"diagnostic_option_id option_id" rather than "int option_index".
(diagnostic_context::option_unspecified_p): Likewise.
(diagnostic_context::classify_diagnostic): Likewise.
(diagnostic_context::option_enabled_p): Likewise.
(diagnostic_context::make_option_name): Likewise.
(diagnostic_context::make_option_url): Likewise.
(diagnostic_context::diagnostic_impl): Likewise.
(diagnostic_context::diagnostic_n_impl): Likewise.
(diagnostic_override_option_index): Rename...
(diagnostic_set_option_id): ...to this, and update for
diagnostic_info field renaming.
(diagnostic_classify_diagnostic): Use "diagnostic_option_id"
rather than "int".
(warning_enabled_at): Likewise.
(option_unspecified_p): Likewise.
gcc/fortran/ChangeLog:
* cpp.cc (cb_cpp_diagnostic_cpp_option): Convert return type from
"int" to "diagnostic_option_id".
(cb_cpp_diagnostic): Update for renaming of
diagnostic_override_option_index to diagnostic_set_option_id.
* error.cc (gfc_warning): Update for renaming of diagnostic_info
field.
(gfc_warning_now_at): Likewise.
(gfc_warning_now): Likewise.
(gfc_warning_internal): Likewise.
gcc/ChangeLog:
* ipa-pure-const.cc: Replace include of "opts.h" with
"opts-diagnostic.h".
(suggest_attribute): Convert param from int to
diagnostic_option_id.
* lto-wrapper.cc (class lto_diagnostic_option_manager): Use
diagnostic_option_id rather than "int".
* opts-common.cc
(compiler_diagnostic_option_manager::option_enabled_p): Likewise.
* opts-diagnostic.h (class gcc_diagnostic_option_manager):
Likewise.
(class compiler_diagnostic_option_manager): Likewise.
* opts.cc (compiler_diagnostic_option_manager::make_option_name):
Likewise.
(gcc_diagnostic_option_manager::make_option_url): Likewise.
* substring-locations.cc
(format_string_diagnostic_t::emit_warning_n_va): Likewise.
(format_string_diagnostic_t::emit_warning_va): Likewise.
(format_string_diagnostic_t::emit_warning): Likewise.
(format_string_diagnostic_t::emit_warning_n): Likewise.
* substring-locations.h
(format_string_diagnostic_t::emit_warning_va): Likewise.
(format_string_diagnostic_t::emit_warning_n_va): Likewise.
(format_string_diagnostic_t::emit_warning): Likewise.
(format_string_diagnostic_t::emit_warning_n): Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Mon, 9 Sep 2024 23:38:12 +0000 (19:38 -0400)]
diagnostics: rename dc.printer to m_printer [PR116613]
Rename diagnostic_context's "printer" field to "m_printer",
for consistency with other fields, and to highlight places
where we currently use this, to help assess feasibility
of supporting multiple output sinks (PR other/116613).
projects / thirdparty / gcc.git / log
