Nathaniel Shead [Wed, 14 Feb 2024 01:26:03 +0000 (12:26 +1100)]
c++: Defer emitting inline variables [PR113708]
Inline variables are vague-linkage, and may or may not need to be
emitted in any TU that they are part of, similarly to e.g. template
instantiations.
Currently 'import_export_decl' assumes that inline variables have
already been emitted when it comes to end-of-TU processing, and so
crashes when importing non-trivially-initialised variables from a
module, as they have not yet been finalised.
This patch fixes this by ensuring that inline variables are always
deferred till end-of-TU processing, unifying the behaviour for module
and non-module code.
* g++.dg/debug/dwarf2/inline-var-1.C: Reference 'a' to ensure it
is emitted.
* g++.dg/debug/dwarf2/inline-var-3.C: Likewise.
* g++.dg/modules/init-7_a.H: New test.
* g++.dg/modules/init-7_b.C: New test.
In the second testcase below, during ahead of time checking of the
non-dependent new-expr we synthesize B's copy ctor, which we expect to
get defined as deleted since A's copy ctor is inaccessible. But during
access checking thereof, enforce_access incorrectly decides to defer it
since we're in a template context according to current_template_parms
(before r14-557 it checked processing_template_decl which got cleared
from implicitly_declare_fn), which leads to the access check leaking out
to the template context that triggered the synthesization, and B's copy
ctor getting declared as non-deleted.
This patch fixes this by using maybe_push_to_top_level to clear the
context (including current_template_parms) before proceeding with the
synthesization. We could do this from implicitly_declare_fn, but it's
better to do it more generally from synthesized_method_walk for sake of
its other callers.
This turns out to fix PR113332 as well: there the lambda context
triggering synthesization was causing maybe_dummy_object to misbehave,
but now synthesization is sufficiently context-independent.
PR c++/113908
PR c++/113332
gcc/cp/ChangeLog:
* method.cc (synthesized_method_walk): Use maybe_push_to_top_level.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-nsdmi11.C: New test.
* g++.dg/template/non-dependent31.C: New test.
Richard Biener [Wed, 14 Feb 2024 11:33:13 +0000 (12:33 +0100)]
tree-optimization/113910 - huge compile time during PTA
For the testcase in PR113910 we spend a lot of time in PTA comparing
bitmaps for looking up equivalence class members. This points to
the very weak bitmap_hash function which effectively hashes set
and a subset of not set bits.
The major problem with it is that it simply truncates the
BITMAP_WORD sized intermediate hash to hashval_t which is
unsigned int, effectively not hashing half of the bits.
This reduces the compile-time for the testcase from tens of minutes
to 42 seconds and PTA time from 99% to 46%.
PR tree-optimization/113910
* bitmap.cc (bitmap_hash): Mix the full element "hash" to
the hashval_t hash.
Rainer Orth [Wed, 14 Feb 2024 13:52:54 +0000 (14:52 +0100)]
testsuite: gdc: Require ucn in gdc.test/runnable/mangle.d etc. [PR104739]
gdc.test/runnable/mangle.d and two other tests come out UNRESOLVED on
Solaris with the native assembler:
UNRESOLVED: gdc.test/runnable/mangle.d compilation failed to produce executable
UNRESOLVED: gdc.test/runnable/mangle.d -shared-libphobos compilation failed
to produce executable
UNRESOLVED: gdc.test/runnable/testmodule.d compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/testmodule.d -shared-libphobos compilation
failed to produce executable
UNRESOLVED: gdc.test/runnable/ufcs.d compilation failed to produce executable
UNRESOLVED: gdc.test/runnable/ufcs.d -shared-libphobos compilation failed
to produce executable
Assembler: mangle.d
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
[...]
since /bin/as lacks UCN support.
Iain recently added UNICODE_NAMES: annotations to the affected tests and
those recently were imported into trunk.
This patch handles the DejaGnu side of things, adding
{ dg-require-effective-target ucn }
to those tests on the fly.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11 (as and gas each),
and x86_64-pc-linux-gnu.
Andrew Pinski [Tue, 13 Feb 2024 21:39:16 +0000 (13:39 -0800)]
vect/testsuite: Fix vect-simd-clone-1[02].c when dg-do default is compile [PR113899]
The vect testsuite will chose the dg-do default based on if it knows the
running target does not support running with the vector extensions enabled
(for easy of testing). The problem is when it is decided the default is compile
instead of run, dg-additional-sources does not work. So the fix is to set
dg-do on these two testcases to run explicitly.
Tested on x86_64 with a hack to check_vect_support_and_set_flags to set the dg-default
to compile.
Jakub Jelinek [Wed, 14 Feb 2024 13:36:44 +0000 (14:36 +0100)]
testsuite: Add %[zt][diox] tests to gcc.dg/format/
On Mon, Feb 12, 2024 at 04:10:33PM +0000, Joseph Myers wrote:
> Please also add some tests of format checking for these modifiers in
> gcc.dg/format/gcc_*.c.
The following patch does that.
Haven't added tests for bad type (but I think we don't have them in
c99-printf* either) for these because it is hard to figure out what
type from {,unsigned }{int,long,long long} size_t/ptrdiff_t certainly
is not, guess one could do that with preprocessor conditionals, e.g.
comparing __PTRDIFF_MAX__ with __INT_MAX__, __LONG_MAX__ and
__LONG_LONG_MAX__ and pick up the one which is different; but we'd need
to find out corresponding effective targets for the expected diagnostics.
2024-02-14 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/format/gcc_diag-1.c (foo): Add tests for z and t modifiers.
* gcc.dg/format/gcc_gfc-1.c (foo): Add tests for ll, z and t modifiers.
Jakub Jelinek [Wed, 14 Feb 2024 13:35:32 +0000 (14:35 +0100)]
pretty-print: Fix up ptrdiff handling for %tu, %to, %tx
This is IMHO more of a theoretical case, I believe my current code
doesn't handle %tu or %to or %tx correctly if ptrdiff_t is not one of
int, long int or long long int. For size_t and %zd or %zi I'm
using va_arg (whatever, ssize_t) and hope that ssize_t is the signed
type corresponding to size_t which C99 talks about.
For ptrdiff_t there is no type for unsigned type corresponding to
ptrdiff_t and I'm not aware of a portable way on the host to get
such a type (the fmt tests use hacks like
#define signed /* Type might or might not have explicit 'signed'. */
typedef unsigned __PTRDIFF_TYPE__ unsigned_ptrdiff_t;
#undef signed
but that only works with compilers which predefine __PTRDIFF_TYPE__),
std::make_unsigned<ptrdiff_t> I believe only works reliably if
ptrdiff_t is one of char, signed char, short, int, long or long long,
but won't work e.g. for __int20__ or whatever other weird ptrdiff_t
the host might have.
The following patch assumes host is two's complement (I think we
rely on it pretty much everywhere anyway) and prints unsigned type
corresponding to ptrdiff_t as unsigned long long printing of
ptrdiff_t value masked with 2ULL * PTRDIFF_MAX + 1. So the only
actual limitation is that it doesn't support ptrdiff_t wider than
long long int.
2024-02-14 Jakub Jelinek <jakub@redhat.com>
* pretty-print.cc (PTRDIFF_MAX): Define if not yet defined.
(pp_integer_with_precision): For unsigned ptrdiff_t printing
with u, o or x print ptrdiff_t argument converted to
unsigned long long and masked with 2ULL * PTRDIFF_MAX + 1.
* error.cc (error_print): For u printing of ptrdiff_t,
print ptrdiff_t argument converted to unsigned long long and
masked with 2ULL * PTRDIFF_MAX + 1.
Richard Biener [Fri, 9 Feb 2024 07:15:44 +0000 (08:15 +0100)]
middle-end/113576 - zero padding of vector bools when expanding compares
The following zeros paddings of vector bools when expanding compares
and the mode used for the compare is an integer mode. In that case
targets cannot distinguish between a 4 element and 8 element vector
compare (both get to the QImode compare optab) so we have to do the
job in the middle-end.
PR middle-end/113576
* expr.cc (do_store_flag): For vector bool compares of vectors
with padding zero that.
* dojump.cc (do_compare_and_jump): Likewise.
Nathaniel Shead [Mon, 12 Feb 2024 01:40:15 +0000 (12:40 +1100)]
c++: Fix error recovery when redeclaring enum in different module [PR99573]
This ensures that with modules enabled, redeclaring an enum in the wrong
module or with the wrong underlying type no longer ICEs.
The patch also rearranges the order of the checks a little because I
think it's probably more important to note that you can't redeclare the
enum all before complaining about mismatched underlying types etc.
As a drive by this patch also adds some missing diagnostic groups, and
rewords the module redeclaration error message to more closely match the
wording used in other places this check is done.
PR c++/99573
gcc/cp/ChangeLog:
* decl.cc (start_enum): Reorder check for redeclaring in module.
Add missing auto_diagnostic_groups.
gcc/testsuite/ChangeLog:
* g++.dg/modules/enum-12.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Rainer Orth [Wed, 14 Feb 2024 10:39:12 +0000 (11:39 +0100)]
testsuite: i386: Skip gcc.target/i386/pr113689-1.c etc. on Solaris [PR113909]
gcc.target/i386/pr113689-[1-3].c FAIL on 64-bit Solaris/x86:
FAIL: gcc.target/i386/pr113689-1.c (test for excess errors)
UNRESOLVED: gcc.target/i386/pr113689-1.c compilation failed to produce executable
FAIL: gcc.target/i386/pr113689-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/pr113689-2.c compilation failed to produce executable
FAIL: gcc.target/i386/pr113689-3.c (test for excess errors)
UNRESOLVED: gcc.target/i386/pr113689-3.c compilation failed to produce executable
with
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-1.c:43:1: sorry, unimplemented: no register available for profiling '-mcmodel=large'
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-2.c:26:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-3.c:15:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported
This happens because i386/sol2.h doesn't define NO_PROFILE_COUNTERS.
As Jason analyzed, Solaris <string.h> declares memchr for C++ as returning
const void * as specified by the C++ standard, while gcc expects the return
type to be void * like in C.
So this patch xfails the test for C++ on Solaris.
Tested on sparc-sun-solaris2.11 and x86_64-pc-linux-gnu.
Tobias Burnus [Tue, 13 Feb 2024 19:55:26 +0000 (20:55 +0100)]
OpenMP: Reject non-const 'condition' trait in Fortran
OpenMP 5.0 only permits constant expressions for the 'condition' trait
in context selectors; this is relaxed in 5.2 but not implemented. In order
to avoid wrong code, it is now rejected.
Additionally, in Fortran, 'condition' should not accept an integer
expression, which is now ensured. Additionally, as 'device_num' should be
a conforming device number, there is now a check on the value.
PR middle-end/113904
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_context_selector): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_context_selector): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_declare_variant): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
* openmp.cc (gfc_match_omp_context_selector): Likewise; rejects
non-const device_num/condition; improve diagnostic.
gcc/ChangeLog:
* omp-general.cc (struct omp_ts_info): Update for splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
* omp-selectors.h (enum omp_tp_type): Replace
OMP_TRAIT_PROPERTY_EXPR by OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
Patrick Palka [Tue, 13 Feb 2024 19:26:48 +0000 (14:26 -0500)]
c++/modules: use optimized crc32 from zlib
The current implementation of bytes::calc_crc computes the checksum one
byte at a time which turns out to be quite slow, accounting for 15% of
streaming in time for a modular Hello World. We have a crc32_unsigned
version that processes 4 bytes at a time which we could use here, but
since we bundle zlib we might as well use its highly optimized crc
routines that can process up to 32 bytes at a time.
So this patch makes us use zlib's crc32 in this hot code path. This
reduces stream in time for a modular Hello World by around 15% for me
with a release compiler.
gcc/cp/ChangeLog:
* Make-lang.in (CFLAGS-cp/module.o): Add $(ZLIBINC).
* module.cc: Include <zlib.h>.
(bytes::calc_crc): Use crc32 from zlib.
(bytes_out::set_crc): Use crc32_combine from zlib.
Patrick Palka [Tue, 13 Feb 2024 19:26:40 +0000 (14:26 -0500)]
c++/modules: ICEs with modular fmtlib
Building modular fmtlib triggered two small modules bugs in C++23 and
C++26 mode respectively (due to libstdc++ header differences).
The first is that a TEMPLATE_DECL having DECL_LANG_SPECIFIC doesn't
necessarily imply that its DECL_TEMPLATE_RESULT has DECL_LANG_SPECIFIC.
So in add_specializations we need to use STRIP_TEMPLATE consistently;
this is a follow-up to r12-7187-gdb84f382ae3dc2.
The second is that get_originating_module_decl was ICEing on class-scope
enumerators injected via using-enum. I suppose we should handle them
like a class-scope entity rather than a non-using-enum enumerator.
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_specializations): Use
STRIP_TEMPLATE consistently.
(get_originating_module_decl): Handle class-scope CONST_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-6_a.C: New test.
* g++.dg/modules/using-enum-3_a.C: New test.
* g++.dg/modules/using-enum-3_b.C: New test.
Patrick Palka [Tue, 13 Feb 2024 19:26:37 +0000 (14:26 -0500)]
c++/modules: reduce lazy loading recursion
It turns out that with modules we can call mangle_decl recursively
which is bad because the global mangling state isn't recursion aware.
The recursion happens from write_closure_type_name, which calls
lambda_function, which performs name lookup, which can trigger lazy
loading, which can call maybe_clone_body for a newly loaded cdtor, which
can inspect DECL_ASSEMBLER_NAME, which enters mangling. This was
observed when using fmtlib as a module with trunk and it leads to a
bogus "mangling conflicts with a previous mangle error" followed by an
ICE from cdtor_comdat_group due to a mangling mismatch.
This patch fixes this by sidestepping lazy loading when performing the
op() lookup in lambda_function, so that we don't accidentally end up
entering mangling recursively. This should be safe since the lazy load
should still get triggered by some other name lookup.
In passing it was noticed that lazy loading can get excessively recursive
ultimately due to the name lookups performed from check_local_shadow,
which may trigger lazy loading, which cause us to instantiate/clone
things, which end up calling check_local_shadow. This patch mitigates
this by implementating an optimization suggested by Jason:
> I think we shouldn't bother with check_local_shadow in a clone or
> instantiation, only when actually parsing.
This reduces the maximum depth of lazy loading recursion for a simple
modular Hello World from ~115 to ~12.
gcc/cp/ChangeLog:
* lambda.cc (lambda_function): Call get_class_binding_direct
instead of lookup_member to sidestep lazy loading.
* name-lookup.cc (check_local_shadow): Punt if we're in a
function context that's not actual parsing.
Harald Anlauf [Tue, 13 Feb 2024 19:19:10 +0000 (20:19 +0100)]
Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]
PR fortran/113866
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): When passing an optional
dummy argument to an optional dummy argument of a bind(c) procedure
and the dummy argument is passed via a CFI descriptor, no special
presence check and passing of a default NULL pointer is needed.
If register_specialization finds a previous declaration and throws the new
one away, we shouldn't still add the new one to
DECL_TEMPLATE_SPECIALIZATIONS.
PR c++/113612
gcc/cp/ChangeLog:
* pt.cc (process_partial_specialization): Return early
on redeclaration.
Marek Polacek [Sat, 10 Feb 2024 15:52:18 +0000 (10:52 -0500)]
c++: SFINAE-unfriendly error on throwing pointer [PR112436]
On the heels of r14-8903, this patch adds further complain parameters
so that we don't emit "invalid use of incomplete type" from inside
a concept.
PR c++/112436
gcc/cp/ChangeLog:
* except.cc (expand_start_catch_block): Pass tf_warning_or_error to
is_admissible_throw_operand_or_catch_parameter.
(build_throw): Pass complain to
is_admissible_throw_operand_or_catch_parameter.
(complete_ptr_ref_or_void_ptr_p): Add a tsubst_flags_t parameter. Use
it. Return bool. Call complete_type_or_maybe_complain instead of
complete_type_or_else.
(is_admissible_throw_operand_or_catch_parameter): Add a tsubst_flags_t
parameter. Use it. Guard error calls.
Richard Biener [Tue, 13 Feb 2024 10:10:57 +0000 (11:10 +0100)]
tree-optimization/113895 - copy_reference_ops_from_ref vs. bitfields
The recent enhancement to discover constant array indices by range
info used by get_ref_base_and_extent doesn't work when the outermost
component reference is to a bitfield because we track the running
offset in the reference ops as bytes. The following does as
ao_ref_init_from_vn_reference and recovers that manually, tracking
the offset for the purpose of discovering the constant array index
in bits instead.
PR tree-optimization/113895
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Track
offset to discover constant array indices in bits, handle
COMPONENT_REF to bitfields.
Rainer Orth [Tue, 13 Feb 2024 12:24:43 +0000 (13:24 +0100)]
libgm2: Fix libm2iso/wraptime.cc compilation on Solaris
As it turned out, my patch to complete the libgm2 autoconf macros works
on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap:
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_gettimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:148:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
148 | return gettimeofday (tv, tz);
| ^~
| |
| void*
In file included from /usr/include/sys/select.h:27,
from /usr/include/sys/types.h:665,
from /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:35:
/usr/include/sys/time.h:444:18: note: initializing argument 1 of 'int gettimeofday(timeval*, void*)'
444 | int gettimeofday(struct timeval *_RESTRICT_KYWD, void *_RESTRICT_KYWD);
| ^
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_settimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:165:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
165 | return settimeofday (tv, tz);
| ^~
| |
| void*
/usr/include/sys/time.h:431:18: note: initializing argument 1 of 'int
settimeofday(timeval*, void*)'
431 | int settimeofday(struct timeval *, void *);
| ^~~~~~~~~~~~~~~~
This happens because on Linux only HAVE_[GS]ETTIMEOFDAY is defined,
while Solaris has both that and HAVE_STRUCT_TIMEZONE, selecting
different implementations.
Fixed by casting tv to struct timeval *.
I thought about changing the signatures instead to take a struct timeval
* instead, but that seemed risky given that there's a
HAVE_STRUCT_TIMEVAL, so would probably break other targets.
Bootstrapped without regressions on i386-pc-solaris2.11,
sparc-sun-solaris2.11, and x86_64-pc-linux-gnu.
Richard Biener [Tue, 13 Feb 2024 10:38:48 +0000 (11:38 +0100)]
tree-optimization/113902 - fix VUSE update in move_early_exit_stmts
The following adjusts move_early_exit_stmts to track the last seen
VUSE instead of getting it from the last store which could be a PHI
where gimple_vuse doesn't work.
PR tree-optimization/113902
* tree-vect-loop.cc (move_early_exit_stmts): Track
last_seen_vuse for VUSE updating.
Tamar Christina [Tue, 13 Feb 2024 11:04:38 +0000 (11:04 +0000)]
middle-end: update vector loop upper bounds when early break vect [PR113734]
When doing early break vectorization we should treat the final iteration as
possibly being partial. This so that when we calculate the vector loop upper
bounds we take into account that final iteration could have done some work.
The attached testcase shows that if we don't then cunroll may unroll the loop an
if the upper bound is wrong we lose a vector iteration.
This is similar to how we adjust the scalar loop bounds for the PEELED case.
gcc/ChangeLog:
PR tree-optimization/113734
* tree-vect-loop.cc (vect_transform_loop): Treat the final iteration of
an early break loop as partial.
gcc/testsuite/ChangeLog:
PR tree-optimization/113734
* gcc.dg/vect/vect-early-break_117-pr113734.c: New test.
When __has_feature was introduced for GCC 14, I included the feature
cxx_constexpr_string_builtins, since of the relevant string builtins
that GCC implements, it seems to support constexpr evaluation of those
builtins.
However, as the PR shows, GCC doesn't implement the full list of
builtins in the clang documentation. After enumerating the builtins,
the clang docs [1] say:
> Support for constant expression evaluation for the above builtins can
> be detected with __has_feature(cxx_constexpr_string_builtins).
and a strict reading of this would suggest we can't really support
constexpr evaluation of a builtin if we don't implement the builtin in
the first place.
So the conservatively correct thing to do seems to be to stop
advertising the feature altogether to avoid failing to build code which
assumes the presence of this feature implies the presence of all the
builtins listed in the clang documentation.
Jakub Jelinek [Tue, 13 Feb 2024 09:33:08 +0000 (10:33 +0100)]
libgcc: Fix UB in FP_FROM_BITINT
As I wrote earlier, I was seeing
FAIL: gcc.dg/torture/bitint-24.c -O0 execution test
FAIL: gcc.dg/torture/bitint-24.c -O2 execution test
with the ia32 _BitInt enablement patch on i686-linux. I thought
floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it
turned out to be UB in it.
If a signed _BitInt to be converted to binary floating point has
(after sign extension from possible partial limb to full limb) one or
more most significant limbs equal to all ones and then in the limb below
(the most significant non-~(UBILtype)0 limb) has the most significant limb
cleared, like for 32-bit limbs
0x81582c05U, 0x0a8b01e4U, 0xc1b8b18fU, 0x2aac2a08U, -1U, -1U
then bitint_reduce_prec can't reduce it to that 0x2aac2a08U limb, so
msb is all ones and precision is negative (so it reduced precision from
161 to 192 bits down to 160 bits, in theory could go as low as 129 bits
but that wouldn't change anything on the following behavior).
But still iprec is negative, -160 here.
For that case (i.e. where we are dealing with an negative input), the
code was using 65 - __builtin_clzll (~msb) to compute how many relevant
bits we have from the msb. Unfortunately that invokes UB for msb all ones.
The right number of relevant bits in that case is 1 though (like for
-2 it is 2 and -4 or -3 3 as already computed) - all we care about from that
is that the most significant bit is set (i.e. the number is negative) and
the bits below that should be supplied from the limbs below.
So, the following patch fixes it by special casing it not to invoke UB.
For msb 0 we already have a special case from before (but that is also
different because msb 0 implies the whole number is 0 given the way
bitint_reduce_prec works - even if we have limbs like ..., 0x80000000U, 0U
the reduction can skip the most significant limb and msb then would be
the one below it), so if iprec > 0, we already don't call __builtin_clzll
on 0.
2024-02-13 Jakub Jelinek <jakub@redhat.com>
* soft-fp/bitint.h (FP_FROM_BITINT): If iprec < 0 and msb is all ones,
just set n to 1 instead of using __builtin_clzll (~msb).
Jakub Jelinek [Tue, 13 Feb 2024 09:32:01 +0000 (10:32 +0100)]
hwint: Fix up preprocessor conditions for GCC_PRISZ/fmt_size_t
Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ
as broke the gengtype on i686-linux before the libiberty fix is certainly
unexpected. size_t is there unsigned int, so expected fmt_size_t is
unsigned int (or some other 32-bit type).
The problem was that I was comparing SIZE_MAX against signed maxima,
but SIZE_MAX is unsigned maximum.
2024-02-13 Jakub Jelinek <jakub@redhat.com>
* hwint.h (GCC_PRISZ, fmt_size_t): Fix preprocessor conditions,
instead of comparing SIZE_MAX against INT_MAX and LONG_MAX compare
it against UINT_MAX and ULONG_MAX.
David Malcolm [Tue, 13 Feb 2024 02:02:09 +0000 (21:02 -0500)]
diagnostics: unbreak 'make gcc.pot'
As noted by Joseph, I broke "make gcc.pot" in r14-6057-g12b67d1e13b3cf
by adding an overloaded format API with the format string in a different
position, leading to this failure:
emit_diagnostic_valist used incompatibly as both --keyword=emit_diagnostic_valist:4
--flag=emit_diagnostic_valist:4:gcc-internal-format and --keyword=emit_diagnostic_valist:5
--flag=emit_diagnostic_valist:5:gcc-internal-format
Fix by replacing the overloaded function with one with a different name.
gcc/analyzer/ChangeLog:
* pending-diagnostic.cc (diagnostic_emission_context::warn):
Update for renaming of emit_diagnostic_valist overload to
emit_diagnostic_valist_meta.
(diagnostic_emission_context::inform): Likewise.
Jerry DeLisle [Mon, 12 Feb 2024 21:12:08 +0000 (13:12 -0800)]
libgfortran: Adjust bytes_left and pos for access="STREAM".
During tab edits, the pos (position) and bytes_used
Variables were not being set correctly for stream I/O.
Since stream I/O does not have 'real' records, the
format buffer active length must be used instead of
the record length variable.
PR libgfortran/109358
libgfortran/ChangeLog:
* io/transfer.c (formatted_transfer_scalar_write): Adjust
bytes_used and pos variable for stream access.
Paul Keir [Mon, 12 Feb 2024 18:15:49 +0000 (18:15 +0000)]
libstdc++: Fix constexpr basic_string union member [PR113294]
A call to `basic_string::clear()` in the std::string move assignment
operator leads to a constexpr error from an access of inactive union
member `_M_local_buf` in the added test (`test_move()`). Changing
`__str._M_local_buf` to `__str._M_use_local_data()` in
`operator=(basic_string&& __str)` fixes this.
PR libstdc++/113294
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string::operator=): Use
_M_use_local_data() instead of _M_local_buf on the moved-from
string.
* testsuite/21_strings/basic_string/modifiers/constexpr.cc
(test_move): New test.
Signed-off-by: Paul Keir <paul.keir@uws.ac.uk> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Jakub Jelinek [Mon, 12 Feb 2024 19:46:04 +0000 (20:46 +0100)]
lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849]
handle_cast handles the simple way all narrowing large/huge bitint to
large/huge bitint conversions and also such widening conversions if we can
assume that the most significant limb is processed using constant index
and both lhs and rhs have same number of limbs.
But, the condition whether we can rely on the most significant limb
being processed using constant index is incorrect.
For m_upwards_2limb it was correct (m_upwards_2limb then is the number
of limbs handled by the loop, so if lhs_type has larger precision than
that, it is handled with constant index), similarly if m_var_msb is set
(on left shifts), it is never handled with constant idx. But in other
cases, like right shifts or non-equality comparisons, or bitquery operations
which operate from most significant to least significant limb, all those
can handle even the most significant limb in a loop when lhs_type has
precision which is a multiple of limb_prec.
So, the following patch punts on the optimization in that case and goes for
the conditionals in the loop for that case.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113849
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use
fast path for widening casts where !m_upwards_2limb and lhs_type
has precision which is a multiple of limb_prec.
The C and C++ FEs when parsing attributes already canonicalize them
(i.e. if they start with __ and end with __ substrings, we remove those).
lookup_attribute already verifies in gcc_assert that the first character
of name is not an underscore, and even lookup_scoped_attribute_spec doesn't
attempt to canonicalize the namespace it is passed. But for some historic
reason it was canonicalizing the name argument, which misbehaves when
an attribute starts with ____ and ends with ____.
I believe it is just wrong to try to canonicalize
lookup_scope_attribute_spec name attribute, it should have been
canonicalized already, in other spots where it is called it is already
canonicalized before.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
PR c++/113674
* attribs.cc (extract_attribute_substring): Remove.
(lookup_scoped_attribute_spec): Don't call it.
Jakub Jelinek [Mon, 12 Feb 2024 17:51:25 +0000 (18:51 +0100)]
testsuite: Fix up gcc.dg/pr113693.c for ia32
As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
enablement patch this testcase FAILs on ia32, there is nothing vectorized in
there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.
The following patch instead prunes it.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/pr113693.c: Guard _BitInt(837) use with
__BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of
dg-message for dbgcnt message.
Jakub Jelinek [Mon, 12 Feb 2024 17:50:16 +0000 (18:50 +0100)]
libiberty: Fix up libiberty_vprintf_buffer_size
When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch,
my first bootstrap failed on i686-linux. That is because I've also had
@@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_
}
subfields = create_field (subfields, t,
- xasprintf (".fld[%lu].%s",
- (unsigned long) aindex,
+ xasprintf (".fld["
+ HOST_SIZE_T_PRINT_UNSIGNED
+ "].%s",
+ (fmt_size_t) aindex,
subname));
subfields->opt = nodot;
if (t == note_union_tp)
hunk in gengtype.cc. While sprintf obviously can print in this case %llu
with fmt_size_t being unsigned long long (that is another bug I'll fix
incrementally), seems libiberty_vprintf_buffer_size
can't deal with that, it ignores h, hh, l, ll and L modifiers and
unconditionally, estimates 30 chars as upper bounds for integers (that is
fine) and then uses (void) va_arg (ap, int); to skip over the argument
regardless if it was %d, %ld, %lld, %hd, %hhd etc.
Now, on x86_64 that happens to work fine probably for all of those,
on ia32 for everything but %lld, because it then skips just one half
of the long long argument; now as there is %s after it, it will try to
compute strlen not from the pointer argument corresponding to %s, but
from the most significant half of the previous long long argument.
So, the following patch attempts not to completely ignore the modifiers,
but figure out from them whether to va_arg an int (used for h and hh as
well), or long, or long long, or size_t, or ptrdiff_t - added support for
z and t there, plus for Windows I64. And also %Lf etc. for long double.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* vprintf-support.c (libiberty_vprintf_buffer_size): Handle
properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX
and L modifier for fFgGeE.
Iain Buclaw [Sun, 4 Feb 2024 21:04:14 +0000 (22:04 +0100)]
d: Fix callee destructor call invalidates the live object [PR113758]
When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.
When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator. This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.
PR d/113758
gcc/d/ChangeLog:
* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
destorys its arguments.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
SET_DECL_VALUE_EXPR on the temporary variable to make it a placeholder
for the TARGET_EXPR_SLOT.
Christophe Lyon [Sat, 10 Feb 2024 21:17:08 +0000 (21:17 +0000)]
gcc/Makefile.in: Always check info dependencies
BUILD_INFO is currently a byproduct of checking makeinfo
presence/version. INSTALL_INFO used to be defined similarly, but was
removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
(svn r38141).
In order to save build time, our CI overrides MAKEINFO=echo, which
works when invoking 'make all' but not for 'make install' in case some
info files need an update.
I noticed this while testing a patch posted on the gcc-patches list,
leading to an error at 'make install' time after updating tm.texi (the
build reported 'new text' in tm.texi and stopped). This is because
'install' depends on 'install-info', which depends on
$(DESTDIR)$(infodir)/gccint.info (among others).
As discussed, it is better to detect this problem during 'make all'
rather than 'make install', and we still want to detect it even if
makeinfo is not available.
This patch makes configure set BUILD_INFO=no-info in case makeinfo is
missing/too old, which effectively makes the build rules no-ops
(x$(BUILD_INFO) != xinfo), and updates Makefile.in so that 'info'
dependencies are still checked.
The initial heap trampoline implementation was targeting 64b
platforms. As the PR demonstrates this creates an issue where it
is expected that the same symbols are exported for 32 and 64b.
Rather than conditionalize the exports and code-gen on x86_64,
this patch provides a basic implementation of the IA32 trampoline.
This also avoids potential user confusion, when a 32b target has
64b multilibs, and vice versa; which is the case for Darwin.
PR target/113855
gcc/ChangeLog:
* config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
available to all sub-targets.
* config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
* config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete.
libgcc/ChangeLog:
* config.host: Add trampoline support to x?86-linux.
* config/i386/heap-trampoline.c (trampoline_insns): Provide
a variant for IA32.
(union ix86_trampoline): Likewise.
(__gcc_nested_func_ptr_created): Implement a basic trampoline
for IA32.
Richard Biener [Fri, 9 Feb 2024 09:16:38 +0000 (10:16 +0100)]
tree-optimization/113831 - wrong VN with structurally identical ref
When we use get_ref_base_and_extent during VN and that ends up using
global ranges to restrict the range of a ref we have to take care
of not using the same expression in the hashtable as for a ref that
could not use that global range. The following attempts to ensure
this by applying similar logic as get_ref_base_and_extent to
copy_reference_ops_from_ref so they behave consistent.
PR tree-optimization/113831
PR tree-optimization/108355
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When
we see variable array indices and get_ref_base_and_extent
can resolve those to constants fix up the ops to constants
as well.
(ao_ref_init_from_vn_reference): Use 'off' member for
ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it.
(valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF.
* gcc.dg/torture/pr113831.c: New testcase.
* gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.
As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't
assemble in a Linux/sparc64 multilib build. However, the root cause is
that the HAVE_EXP10* macros are never defined. While I was at it, I
checked for other cases where the code uses HAVE_* macros that are
missing from config.h.in.
This patch adds the missing checks, changes the configure checks where
the names don't match what's used in the code, or corrects the code to
use the right names.
So far tested on sparc64-unknown-linux-gnu by building libgm2 (32 and
64-bit) and running the gm2 tests.
Pan Li [Sat, 10 Feb 2024 10:59:55 +0000 (18:59 +0800)]
RISC-V: Fix misspelled term args in error_at message
When build with "-Werror=format-diag", there will be one misspelled
term args as below. This patch would like fix it by taking the term
arguments instead.
../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree,
vec<tree_node*, va_gc>*)':
../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error:
misspelled term 'args' in format; use 'arguments' instead
[-Werror=format-diag]
4633 | error_at (loc, "no matching function call to %qE with empty
args", fndecl);
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin):
Replace args to arguments for misspelled term.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: Adjust the test cases.
Georg-Johann Lay [Mon, 12 Feb 2024 10:10:48 +0000 (11:10 +0100)]
AVR: target/112944 - Addendum: Link code to initialize NVMCTRL_CTRLB.FLMAP
For devices that see a part for the flash memory in the RAM address space,
bit-field NVMCTRL_CTRLB.FLMAP must match the value of symbol __flmap.
This is achieved by dragging in startup code from lib<mcu>.a.
The mechanism is the same like for libgcc's __do_copy_data and __do_clear_bss.
The code is implemented in AVR-LibC #931 and can be dragged by referencing
__do_flmap_init.
In addition to setting FLMAP, that code also sets bit FLMAPLOCK provided
symbol __flmap_lock has a non-zero value. This protects FLMAP from future
changes.
When the __do_flmap_init code is not wanted, the symbol can be satisfied by
linking with -Wl,--defsym,__do_flmap_init=0
gcc/
PR target/112944
* config/avr/gen-avr-mmcu-specs.cc (print_mcu) [have_flmap]:
<*link_rodata_in_ram>: Spec undefs symbol __do_flmap_init
when not linked with -mrodata-in-ram.
testsuite: Update test case to comply with GCC14 changes
The test case for PR97969 needs updates in order to comply with recent
changes in GCC14. Without these changes, failures like this can be seen
on arm-none-eabi:
.../pr97969.c:6:9: error: type defaults to 'int' in declaration of 'a' [-Wimplicit-int]
.../pr97969.c:34:1: error: return type defaults to 'int' [-Wimplicit-int]
.../pr97969.c:40:3: error: implicit declaration of function 'ae' [-Wimplicit-function-declaration]
.../pr97969.c:42:3: error: implicit declaration of function 'af' [-Wimplicit-function-declaration]
.../pr97969.c:43:7: error: implicit declaration of function 'ag' [-Wimplicit-function-declaration]
.../pr97969.c:46:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
.../pr97969.c:48:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
.../pr97969.c:50:8: error: implicit declaration of function 'setjmp' [-Wimplicit-function-declaration]
.../pr97969.c:51:5: error: implicit declaration of function 'ah' [-Wimplicit-function-declaration]
.../pr97969.c:52:5: error: implicit declaration of function 'ai' [-Wimplicit-function-declaration]
.../pr97969.c:54:5: error: implicit declaration of function 'aj' [-Wimplicit-function-declaration]
Patch has been verified on Linux.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr97969.c: Update to comply with GCC14 changes.
Marek Polacek [Fri, 2 Feb 2024 19:53:01 +0000 (14:53 -0500)]
c++: DR2237, cdtor and template-id tweaks [PR107126]
Since my r11-532 changes to implement DR2237, for this test:
template<typename T>
struct S {
S<T>();
};
in C++20 we emit the ugly:
q.C:3:8: error: expected unqualified-id before ')' token
3 | S<T>();
which doesn't explain what the problem is. This patch improves that
diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
diagnostic. We now say:
q.C:3:7: warning: template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor]
3 | S<T>();
q.C:3:7: note: remove the '< >'
This patch also fixes
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8>
where the C++20 diagnostic was missing altogether: The problem was that I checked
for CPP_TEMPLATE_ID too early, at a point at which cp_parser_template_id may not
have been called yet. So let's check for it at the end of the function, after
the tentative parse and rollback.
-Wc++20-compat triggered in libitm/; I sent a patch for that.
DR 2237
PR c++/107126
PR c++/97202
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): In C++20 or with -Wc++20-compat,
turn on -Wtemplate-id-cdtor.
* c.opt (Wtemplate-id-cdtor): New.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error to
a pedwarn.
(cp_parser_constructor_declarator_p): Likewise.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wtemplate-id-cdtor.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2237.C: Adjust dg-error.
* g++.dg/parse/constructor2.C: Likewise.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.pt/ctor2.C: Likewise.
* g++.dg/DRs/dr2237-2.C: New test.
* g++.dg/DRs/dr2237-3.C: New test.
* g++.dg/DRs/dr2237-4.C: New test.
* g++.dg/DRs/dr2237-5.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-1.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-2.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-3.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-4.C: New test.
Jakub Jelinek [Sat, 10 Feb 2024 11:52:23 +0000 (12:52 +0100)]
lower-bitint: Fix up .{ADD,SUB}_OVERFLOW lowering
torture/bitint-37.c test FAILed on i686-linux e.g. on
signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
__builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
the IL, 2 in a loop (which handles the first 8 limbs), then one partial
limb (we use 63 bits from that) and finally last_ovf case due to the
mixing of signed vs. unsigned.
But with 32-bit limbs, we use 5 .UADDC calls in the IL, 2 in a loop (which
handles the first 16 limbs), then one full limb above that, one partial
(31 bits) and finally last_ovf case, and for the last_ovf case the code
computed incorrect idx and so partly did the wrong thing, e.g. overwrote
the result from the previous .UADDC.
Fixed thusly.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
* gimple-lower-bitint.cc (itint_large_huge::lower_addsub_overflow): Fix
computation of idx for i == 4 of bitint_prec_huge.
Jakub Jelinek [Sat, 10 Feb 2024 11:51:39 +0000 (12:51 +0100)]
libgcc: Fix a bug in _BitInt -> dfp conversions
The ia32 _BitInt support revealed a bug in floatbitint?d.c.
As can be even guessed from how the code is written in the loop,
the intention was to set inexact to non-zero whenever the remainder
after division wasn't zero, but I've ended up just checking whether
the 2 least significant limbs of the remainder were non-zero.
Now, in the dfp/bitint-4.c test in one case the remainder happens
to have least significant 64 bits zero and then the higher limbs are
non-zero; with 32-bit limbs that means 2 least significant limbs are zero
and so the code acted as if it was exactly divisible.
Fixed thusly.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder
limbs into inexact rather than just first two.
* soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise.
* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
Jakub Jelinek [Sat, 10 Feb 2024 11:50:52 +0000 (12:50 +0100)]
libgcc: Fix BIL_TYPE_SIZE == 32 support in _BitInt <-> dfp support
I've tried last night to enable _BitInt support for i?86-linux, and
a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly
didn't do what it was supposed to do.
Jakub Jelinek [Sat, 10 Feb 2024 10:28:00 +0000 (11:28 +0100)]
gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754]
As the following testcases show, the gimple-low outlining of assume
magic functions handled volatile automatic vars (including
parameters/results) like non-volatile ones except it copied volatile
to the new PARM_DECL, which has the undesirable effect that a load
from the volatile var is passed to IFN_ASSUME and so there is a
side-effect there even when side-effects of the assume attribute
shouldn't be evaluated.
The following patch fixes that by passing address of the volatile
variables/parameters/results instead and doing loads or stores from it
or to it where it was originally accessed in the assume attribute
expression.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
PR middle-end/110754
* gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE
decls create PARM_DECL with pointer to original type, set
TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE,
DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared.
(adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls
wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF.
(lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR
of the var as argument.
* gcc.dg/attr-assume-6.c: New test.
* g++.dg/cpp23/attr-assume12.C: New test.
Jakub Jelinek [Sat, 10 Feb 2024 10:27:14 +0000 (11:27 +0100)]
Add %[zt][diox] support to pretty-print
In the previous patch I haven't touched the gcc diagnostic routines,
using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
want the strings to be translatable. We already have %w[diox] for
HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
gcc/
* pretty-print.cc (pp_integer_with_precision): Handle precision 3 for
size_t and precision 4 for ptrdiff_t. Formatting fix.
(pp_format): Document %{t,z}{d,i,u,o,x}. Implement t and z modifiers.
Formatting fixes.
(test_pp_format): Test t and z modifiers.
* gcc.cc (read_specs): Use %td instead of %ld and casts to long.
gcc/c-family/
* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
z modifiers.
gcc/fortran/
* error.cc (error_print): Handle z and t modifiers on d, i and u.
* check.cc (gfc_check_transfer): Use %zd instead of %ld and casts to
long.
* primary.cc (gfc_convert_to_structure_constructor): Use %td instead
of %ld and casts to long.
Jakub Jelinek [Sat, 10 Feb 2024 10:26:26 +0000 (11:26 +0100)]
Use HOST_SIZE_T_PRINT_* and HOST_WIDE_INT_T_PRINT_* some more
I went through suspicios %l in format strings of *printf family functions
combined with casts to (long) or (unsigned long) and tried to find out the
types of the original expressions that were cast.
Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_*
macros together with cast to fmt_size_t for those, and then there were
quite a few HOST_WIDE_INTs cast to long, used HOST_WIDE_INT_PRINT_* for
those without casts. There was one case of a weird unsigned int variable
used with %lu and (long) cast too.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
gcc/
* ipa-icf.cc (sem_item_optimizer::process_cong_reduction,
sem_item_optimizer::dump_cong_classes): Use HOST_SIZE_T_PRINT_UNSIGNED
and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
* tree.cc (print_debug_expr_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
(print_value_expr_statistics, print_type_hash_statistics): Likewise.
* dwarf2out.cc (output_macinfo_op): Use HOST_WIDE_INT_PRINT_UNSIGNED
instead of "%lu" and casts to unsigned long.
* gcov-dump.cc (dump_gcov_file): Use %u instead of %lu and casts to
unsigned long.
* tree-ssa-dom.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* cfgexpand.cc (dump_stack_var_partition): Use
HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu"
and casts to unsigned long.
* gengtype.cc (adjust_field_rtx_def): Likewise.
* tree-into-ssa.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* postreload-gcse.cc (dump_hash_table): Likewise.
* ggc-page.cc (alloc_page): Use HOST_SIZE_T_PRINT_UNSIGNED
and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
(ggc_internal_alloc, ggc_free): Likewise.
* genpreds.cc (write_lookup_constraint_1): Likewise.
(write_insn_constraint_len): Likewise.
* tree-dfa.cc (dump_dfa_stats): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* varasm.cc (output_constant_pool_contents): Use
HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long.
* var-tracking.cc (dump_var): Likewise.
gcc/c-family/
* c-ada-spec.cc (dump_template_types): Use HOST_SIZE_T_PRINT_UNSIGNED
and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
gcc/c/
* c-decl.cc (get_parm_array_spec): Use HOST_WIDE_INT_PRINT_UNSIGNED
instead of "%lu" and casts to unsigned long or unsigned long long.
gcc/cp/
* tree.cc (debug_binfo): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld"
and casts to long.
* pt.cc (print_template_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* class.cc (dump_class_hierarchy_1): Use HOST_WIDE_INT_PRINT_UNSIGNED
instead of "%lu" and casts to unsigned long. For TYPE_ALIGN, use
%u instead of %lu and drop casts to unsigned long.
* parser.cc (cp_lexer_peek_nth_token): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
gcc/fortran/
* trans-common.cc (build_common_decl): Use %wu instead of %lu and
casts to unsigned long.
* resolve.cc (resolve_ordinary_assign): Use %wd instead of %ld and
casts to long.
* array.cc (gfc_resolve_character_array_constructor): Likewise.
* data.cc (create_character_initializer): Likewise.
gcc/jit/
* jit-playback.cc (new_bitcast): Use HOST_WIDE_INT_PRINT_DEC instead
of "%ld" and casts to long.
gcc/lto/
* lto-common.cc (print_lto_report_1): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long. Use
%d instead of %ld and casts to long for searches and collisions.
c++: testcases for PR113545 (constexpr with switch and passing non-constexpr parameter)
Test-cases, with constexpr-reinterpret3.C dg-ice:ing the PR c++/113545 bug.
Regarding the request in the comment, A dg-do run when there's an ICE
will cause some CI's to signal an error for the run being "UNRESOLVED"
(compilation failed to produce executable). Note that dejagnu (1.6.3)
itself doesn't consider this an error.
gcc/testsuite:
PR c++/113545
* g++.dg/cpp1y/constexpr-reinterpret3.C,
g++.dg/cpp1y/constexpr-reinterpret4.C: New tests.
Gaius Mulley [Sat, 10 Feb 2024 02:18:54 +0000 (02:18 +0000)]
PR modula2/113848 modula2 does not build with clang
Re-write address arithmetic in gm2-libs/SArgs.mod:GetArg
to avoid (void *) computation. mc treats ADDRESS as (char *)
but does not cast user type (PtrToChar) to (char *) when
performing address arithmetic.
Marek Polacek [Fri, 9 Feb 2024 17:03:50 +0000 (12:03 -0500)]
c++: fix ICE with __type_pack_element [PR113834]
Here we crash on this invalid code because we seem to infinitely recurse
and end up with __type_pack_element with index that doesn't tree_fits_shwi_p
which then crashes on tree_to_shwi.
Thanks to Jakub for suggesting a nicer fix than my original one.
PR c++/113834
gcc/cp/ChangeLog:
* semantics.cc (finish_type_pack_element): Perform range checking
before tree_to_shwi.
Marek Polacek [Tue, 6 Feb 2024 20:35:16 +0000 (15:35 -0500)]
c++: make build_throw SFINAE-friendly [PR98388]
Here the problem is that we give hard errors while substituting
template parameters during overload resolution of is_throwable
which has an invalid throw in decltype.
The backtrace shows that fn_type_unification -> instantiate_template
-> tsubst* passes complain=0 as expected, but build_throw doesn't
have a complain parameter. So let's add one. Also remove a redundant
local variable which I should have removed in my P2266 patch.
There's still one problem for which I opened <https://gcc.gnu.org/PR113853>.
We need to patch up treat_lvalue_as_rvalue_p and remove the dg-bogus.
Thanks to Patrick for notifying me of this PR. This doesn't fully fix
113789; there I think I'll have to figure our why a candidate wasn't
discarded from the overload set.
PR c++/98388
gcc/cp/ChangeLog:
* coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
to build_throw.
(morph_fn_to_coro): Likewise.
* cp-tree.h (build_throw): Adjust.
* except.cc (expand_end_catch_block): Pass tf_warning_or_error to
build_throw.
(build_throw): Add a tsubst_flags_t parameter. Use it. Remove
redundant variable. Guard an inform call.
* parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
to build_throw.
* pt.cc (tsubst_expr) <case THROW_EXPR>: Pass complain to build_throw.
libcc1/ChangeLog:
* libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
build_throw.
Harald Anlauf [Thu, 8 Feb 2024 20:51:38 +0000 (21:51 +0100)]
Fortran: error recovery on arithmetic overflow on unary operations [PR113799]
PR fortran/113799
gcc/fortran/ChangeLog:
* arith.cc (reduce_unary): Remember any overflow encountered during
reduction of unary arithmetic operations on array constructors and
continue, and return error status, but terminate on serious errors.
gcc/testsuite/ChangeLog:
* gfortran.dg/arithmetic_overflow_2.f90: New test.
Ken Matsui [Thu, 8 Feb 2024 08:12:07 +0000 (00:12 -0800)]
libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_same
Since is_same has a fallback native implementation, and
_GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which
implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME
definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
Removed.
* include/std/type_traits (is_same): Use
_GLIBCXX_USE_BUILTIN_TRAIT instead of
_GLIBCXX_HAVE_BUILTIN_IS_SAME.
(is_same_v): Likewise.
Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Patrick Palka [Fri, 9 Feb 2024 17:40:28 +0000 (12:40 -0500)]
c++/modules: anon union member of as-base class [PR112580]
Here when streaming in the fields of the as-base version of
_Formatting_scanner<int> we end up overwriting ANON_AGGR_TYPE_FIELD
of the anonymous union type, since it turns out this type is shared
between the original FIELD_DECL and the as-base FIELD_DECL copy (copied
during layout_class_type). ANON_AGGR_TYPE_FIELD first gets properly set
to the original FIELD_DECL when streaming in the canonical definition of
_Formatting_scanner<int>, and then gets overwritten to the as-base
FIELD_DECL when streaming in the the as-base definition. This leads to
lookup_anon_field later giving the wrong answer when resolving the
_M_values use at instantiation time.
This patch makes us avoid overwriting ANON_AGGR_TYPE_FIELD when streaming
in an as-base class definition; it should already be properly set at that
point.
PR c++/112580
gcc/cp/ChangeLog:
* module.cc (trees_in::read_class_def): When streaming in
an anonymous union field of an as-base class, don't overwrite
ANON_AGGR_TYPE_FIELD.
gcc/testsuite/ChangeLog:
* g++.dg/modules/anon-3_a.H: New test.
* g++.dg/modules/anon-3_b.C: New test.
Jakub Jelinek [Fri, 9 Feb 2024 15:17:08 +0000 (16:17 +0100)]
lower-bitint: Fix handling of VIEW_CONVERT_EXPRs to minimally supported huge INTEGER_TYPEs [PR113783]
On the following testcases memcpy lowering folds the calls to
reading and writing of MEM_REFs with huge INTEGER_TYPEs - uint256_t
with OImode or uint512_t with XImode. Further optimization turn
the load from MEM_REF from the large/huge _BitInt var into VIEW_CONVERT_EXPR
from it to the uint256_t/uint512_t. The backend doesn't really
support those except for "movoi"/"movxi" insns, so it isn't possible
to handle it like casts to supportable INTEGER_TYPEs where we can
construct those from individual limbs - there are no OImode/XImode shifts
and the like we can use.
So, the following patch makes sure for such VCEs that the SSA_NAME operand
of the VCE lives in memory and then turns it into a VIEW_CONVERT_EXPR so
that we actually load the OImode/XImode integer from memory (i.e. a mov).
We need to make sure those aren't merged with other
operations in the gimple_lower_bitint hunks.
For SSA_NAMEs which have underlying VAR_DECLs that is all we need, those
VAR_DECL have ARRAY_TYPEs.
For SSA_NAMEs which have underlying PARM_DECLs or RESULT_DECLs those have
BITINT_TYPE and I had to tweak expand_expr_real_1 for that so that it
doesn't try convert_modes on those when one of the modes is BLKmode - we
want to fall through into the adjust_address on the MEM.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113783
* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Look
through VIEW_CONVERT_EXPR for final cast checks. Handle
VIEW_CONVERT_EXPRs from large/huge _BitInt to > MAX_FIXED_MODE_SIZE
INTEGER_TYPEs.
(gimple_lower_bitint): Don't merge mergeable operations or other
casts with VIEW_CONVERT_EXPRs to > MAX_FIXED_MODE_SIZE INTEGER_TYPEs.
* expr.cc (expand_expr_real_1): Don't use convert_modes if either
mode is BLKmode.
Jakub Jelinek [Fri, 9 Feb 2024 10:51:08 +0000 (11:51 +0100)]
hwint: Introduce HOST_SIZE_T_PRINT_*
build_conflict_bit_table uses %ld format string for
(long) some_int_expression * sizeof (something)
argument, that doesn't work on LLP64 hosts because the
expression has then size_t aka unsigned long long type there.
It can be fixed with
(long) (some_int_expression * sizeof (something))
but it means the value is truncated if it doesn't fit into long.
Ideally we'd use %zd or %zu modifiers here, but it is unclear if we
can rely on it on all hosts, it has been introduced in C99 and C++11
includes C99 by reference, but in reality whether this works or not
depends on the host C library and some of them are helplessly obsolete.
This patch instead introduces new macros HOST_SIZE_T_PRINT_* which
one can use in *printf family function format strings and cast to
fmt_size_t type.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
HOST_SIZE_T_PRINT_HEX_PURE): Define.
* ira-conflicts.cc (build_conflict_bit_table): Use it. Formatting
fixes.
Jakub Jelinek [Fri, 9 Feb 2024 10:08:33 +0000 (11:08 +0100)]
expand: Fix asm goto expansion [PR113415]
The asm goto expansion ICEs on the following testcase (which normally
is rejected later), because expand_asm_stmt emits the code to copy
the large var out of the out operand to its memory location into
after_rtl_seq ... after_rtl_end sequence and because it is asm goto,
it duplicates the sequence on each successor edge of the asm goto.
The problem is that with -mstringop-strategy=byte_loop that sequence
contains loops, so CODE_LABELs, JUMP_INSNs, with other strategies
could contain CALL_INSNs etc.
But the copying is done using a loop doing
emit_insn (copy_insn (PATTERN (curr)));
which does the right thing solely for INSNs, it will do the wrong thing
for JUMP_INSNs, CALL_INSNs, CODE_LABELs (with RTL checking even ICE on
them), BARRIERs and the like.
The following patch partially fixes it (with the hope that such stuff only
occurs in asms that really can't be accepted; if one uses say "=rm" or
"=g" constraint then the operand uses the memory directly and nothing is
copied) by using the
duplicate_insn_chain function which is used e.g. in RTL loop unrolling and
which can handle JUMP_INSNs, CALL_INSNs, BARRIERs etc.
As it is meant to operate on sequences inside of basic blocks, it doesn't
handle CODE_LABELs (well, it skips them), so if we need a solution that
will be correct at runtime here for those cases, we'd need to do further
work (e.g. still use duplicate_insn_chain, but if we notice any CODE_LABELs,
walk the sequence again, add copies of the CODE_LABELs and then remap
references to the old CODE_LABELs in the copied sequence to the new ones).
Because as is now, if the code in one of the sequence copies (where the
CODE_LABELs have been left out) decides to jump to such a CODE_LABEL, it
will jump to the CODE_LABEL which has been in the original sequence (which
the code emits on the last edge, after all, duplicating the sequence
EDGE_COUNT times and throwing away the original was wasteful, compared to
doing that just EDGE_COUNT - 1 times and using the original.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113415
* cfgexpand.cc (expand_asm_stmt): For asm goto, use
duplicate_insn_chain to duplicate after_rtl_seq sequence instead
of hand written loop with emit_insn of copy_insn and emit original
after_rtl_seq on the last edge.
Jakub Jelinek [Fri, 9 Feb 2024 10:07:34 +0000 (11:07 +0100)]
lower-bitint: Fix up additions of EH edges [PR113818]
Due to -fnon-call-exceptions the bitint lowering adds new EH edges
in various places, so that the EH edge points from handling (e.g. load or
store) of each of the limbs. The problem is that the EH edge destination
as shown in the testcase can have some PHIs. If it is just a virtual
PHI, no big deal, the pass uses TODO_update_ssa_only_virtuals, but if
it has other PHIs, I think we need to copy the values from the preexisting
corresponding EH edge (which is from the original stmt to the EH pad)
to the newly added EH edge, so that the PHI arguments are the same rather
than missing (which ICEs during checking at the end of the pass).
This patch adds a function to do that and uses it whenever adding EH edges.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113818
* gimple-lower-bitint.cc (add_eh_edge): New function.
(bitint_large_huge::handle_load,
bitint_large_huge::lower_mergeable_stmt,
bitint_large_huge::lower_muldiv_stmt): Use it.
Jakub Jelinek [Fri, 9 Feb 2024 10:06:00 +0000 (11:06 +0100)]
lower-bitint: Attempt not to emit always true conditions in handle_cast [PR113774]
The following patch is the optimization part of PR113774, where in
handle_cast we emit some conditionals which are always true and presumably
VRP would figure that out later and clean it up, except that instead
thread1 is invoked and threads everything through the conditions, so we end
up with really ugly code which is hard to be cleaned up later and then
run into PR113831 VN bug and miscompile stuff.
handle_cast computes low and high as limb indexes, where idx < low
doesn't need any special treatment, just uses the operand's limb,
idx >= high cases all the bits in the limb are an extension (so, for
unsigned widening cast all those bits are 0, for signed widening cast
all those bits are equal to the in earlier code computed sign mask,
narrowing cast don't trigger this code) and then the idx == low && idx <
high case if it exists need special treatment (some bits are copied, others
extended, or all bits are copied but sign mask needs to be computed).
The code already attempted to optimize away some unneeded casts, in the
first hunk below e.g. for the case like 257 -> 321 bit extension, where
low is 4 and high 5 and we use a loop handling the first 4 limbs (2
iterations) with m_upwards_2limb 4 - no special handling is needed in the
loop, and the special handling is done on the first limb after the loop
and then the last limb after the loop gets the extension only, or
in the second hunk where can emit a single comparison instead of
2 e.g. for the low == high case - that must be a zero extension from
multiple of limb bits, say 192 -> 328, or for the case where we know
the idx == low case happens in the other limb processed in the loop, not
the current one.
But the testcase shows further cases where we always know some of the
comparisons can be folded to true/false, in particular there is
255 -> 257 bit zero extension, so low 3, high 4, m_upwards_2limb 4.
The loop handles 2 limbs at the time and for the first limb we were
emitting idx < low ? operand[idx] : 0; but because idx goes from 0
with step 2 2 iterations, idx < 3 is always true, so we can just
emit operand[idx]. This is handled in the first hunk. In addition
to fixing it (that is the " - m_first" part in there) I've rewritten
it using low to make it more readable.
Similarly, in the other limb we were emitting
idx + 1 <= low ? (idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx]) : 0
but idx + 1 <= 3 is always true in the loop, so all we should emit is
idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx],
Unfortunately for the latter, when single_comparison is true, we emit
just one comparison, but the code which fills the branches will fill it
with the operand[idx] and 0 cases (for zero extension, for sign extension
similarly), not the operand[idx] (aka copy) and operand[idx] & 0x7ff....ff
(aka most significant limb of the narrower precision) cases. Instead
of making the code less readable by using single_comparison for that and
handling it in the code later differently I've chosen to just emit
a condition which will be always true and let cfg cleanup clean it up.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113774
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't
emit any comparison if m_first and low + 1 is equal to
m_upwards_2limb, simplify condition for that. If not
single_comparison, not m_first and we can prove that the idx <= low
comparison will be always true, emit instead of idx <= low
comparison low <= low such that cfg cleanup will optimize it at
the end of the pass.
testsuite: Pattern does not match when using --specs=nano.specs
When running the testsuite for newlib nano, the --specs=nano.specs
option is used. This option prepends cpp_unique_options with
"-isystem =/include/newlib-nano" so that the newlib nano header files
override the newlib standard ones. As the -isystem option is prepended,
the -quiet option is no longer the first option to cc1. Adjust the test
accordingly.
Patch has been verified on Windows and Linux.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/options.exp: Allow other options before the
-quite option for cc1.
Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled
projects / thirdparty / gcc.git / log
