[PATCH] hwint: Fix up preprocessor conditions for GCC_PRISZ/fmt_size_t
Hi!
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.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
2024-02-13 Jakub Jelinek
* 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.
--- gcc/hwint.h.jj 2024-02-09 11:59:17.444974906 +0100
+++ gcc/hwint.h 2024-02-12 18:53:51.287281199 +0100
@@ -120,10 +120,10 @@ typedef HOST_WIDE_INT __gcc_host_wide_in
So, instead of doing fprintf ("%zu\n", sizeof (x) * y); use
fprintf (HOST_SIZE_T_PRINT_UNSIGNED "\n",
(fmt_size_t) (sizeof (x) * y)); */
-#if SIZE_MAX <= INT_MAX
+#if SIZE_MAX <= UINT_MAX
# define GCC_PRISZ ""
# define fmt_size_t unsigned int
-#elif SIZE_MAX <= LONG_MAX
+#elif SIZE_MAX <= ULONG_MAX
# define GCC_PRISZ HOST_LONG_FORMAT
# define fmt_size_t unsigned long int
#else
Jakub
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #4 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #2) This is not about the question if the C library supports these types as `uint128_t`. This is primarily to provide `printf` etc *interface* support for the builtin type by means of the new C23 specifiers. C compiler and C library should be independent on this as much as possible, because all combinations of old/new compile/library should work without problems. The musl implementation of the length specifiers does for example not rely any compiler support for the types. It only uses a convention on how to pass 128 bit types as `va_arg` and which of the two 64 halves is high and which is low. For the format checker in the compiler this just asks: - accept w128 and wf128 specifiers iff the platform supports 128 bit integer types - check if the corresponding argument has such a type
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comment #2 from Zhendong Su ---
Another related test:
[534] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240213 (experimental) (GCC)
[535] %
[535] % gcctk -O1 small.c
during GIMPLE pass: cunroll
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1156
3 | int main() {
| ^~~~
0x86357f copy_reference_ops_from_ref
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:1156
0x1298c4a valueize_shared_reference_ops_from_ref
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:1837
0x1298c4a valueize_shared_reference_ops_from_ref
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:1832
0x1298c4a vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:4042
0x129d574 visit_reference_op_load
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:5831
0x129d574 visit_stmt
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:6352
0x129dc1f process_bb
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:8124
0x129f4de do_rpo_vn_1
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:8725
0x12a0e53 do_rpo_vn(function*, edge_def*, bitmap_head*, bool, bool, bool,
vn_lookup_kind)
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:8829
0x11f6529 tree_unroll_loops_completely
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1554
0x11f6663 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1673
0x11f6663 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1663
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/113822] aarch64_evpc_reencode could/should use new_shrunk_vector instead of manually doing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822 --- Comment #2 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645448.html
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I need to keep an eye on this while working on related issues.
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:6caec7d9ec37e60e718a12934c85bac9c12757ac commit r14-8947-g6caec7d9ec37e60e718a12934c85bac9c12757ac Author: Steve Kargl Date: Mon Feb 12 20:41:02 2024 -0800 Fortran: Set the length of an allocatable character PR fortran/113883 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_deferred_array): Set length to zero, avoiding extraneous diagnostics. gcc/testsuite/ChangeLog: * gfortran.dg/allocatable_length.f90: New test.
[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #24 from Tamar Christina ---
The case I thought would go wrong with the above fix is:
#include
#include
#include
#define N 306
#define NEEDLE 135
__attribute__ ((noipa, noinline))
int use(int x[N])
{
printf("res=%d\n", x[NEEDLE]);
return x[NEEDLE];
}
__attribute__ ((noipa, noinline))
int foo (int i, unsigned short parse_tables_n)
{
int table[N];
memset (table, -1, sizeof (table));
parse_tables_n >>= 9;
parse_tables_n += 9;
while (i < N && parse_tables_n--)
table[i++] = 0;
return use (table);
}
int main ()
{
if (foo (0, 0x) != 0)
abort ();
return 0;
}
---
but this seems fine because of the bias_for_lowest which I now understand to be
there to account for this.
So starting a regtest for that patch.
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #38 from H.J. Lu --- The new glibc patch set covers both i386 and x86-64: https://patchwork.sourceware.org/project/glibc/list/?series=30854
[Bug libstdc++/107538] std::pow(10, std::complex(NaN, 1)) aborts with -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107538 --- Comment #6 from Orion Poplawski --- Any progress on determining whether or not this is a valid assertion?
Re: [PATCH] c++: SFINAE-unfriendly error on throwing pointer [PR112436]
On 2/10/24 15:27, Marek Polacek wrote:
Probably stage1 material but it should be safe...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Yeah, OK, this should go in along with the 98388 patch.
-- >8 --
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.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr112436.C: New test.
---
gcc/cp/except.cc | 66 ++-
.../g++.dg/cpp2a/concepts-pr112436.C | 9 +++
2 files changed, 44 insertions(+), 31 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-pr112436.C
diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
index ea3d6f57396..f1ffda22fd3 100644
--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -39,8 +39,8 @@ static tree do_end_catch (tree);
static void initialize_handler_parm (tree, tree);
static tree do_allocate_exception (tree);
static tree wrap_cleanups_r (tree *, int *, void *);
-static int complete_ptr_ref_or_void_ptr_p (tree, tree);
-static bool is_admissible_throw_operand_or_catch_parameter (tree, bool);
+static bool is_admissible_throw_operand_or_catch_parameter (tree, bool,
+ tsubst_flags_t);
/* Sets up all the global eh stuff that needs to be initialized at the
start of compilation. */
@@ -398,7 +398,8 @@ expand_start_catch_block (tree decl)
if (decl)
{
- if (!is_admissible_throw_operand_or_catch_parameter (decl, false))
+ if (!is_admissible_throw_operand_or_catch_parameter (decl, false,
+ tf_warning_or_error))
decl = error_mark_node;
type = prepare_eh_type (TREE_TYPE (decl));
@@ -626,11 +627,10 @@ build_throw (location_t loc, tree exp, tsubst_flags_t
complain)
warning_at (loc, 0,
"throwing NULL, which has integral, not pointer type");
- if (exp != NULL_TREE)
-{
- if (!is_admissible_throw_operand_or_catch_parameter (exp, true))
- return error_mark_node;
-}
+ if (exp && !is_admissible_throw_operand_or_catch_parameter (exp,
+ /*is_throw=*/true,
+ complain))
+return error_mark_node;
if (! doing_eh ())
return error_mark_node;
@@ -815,28 +815,26 @@ build_throw (location_t loc, tree exp, tsubst_flags_t
complain)
Return the zero on failure and nonzero on success. FROM can be
the expr or decl from whence TYPE came, if available. */
-static int
-complete_ptr_ref_or_void_ptr_p (tree type, tree from)
+static bool
+complete_ptr_ref_or_void_ptr_p (tree type, tree from, tsubst_flags_t complain)
{
- int is_ptr;
-
/* Check complete. */
- type = complete_type_or_else (type, from);
+ type = complete_type_or_maybe_complain (type, from, complain);
if (!type)
-return 0;
+return false;
/* Or a pointer or ref to one, or cv void *. */
- is_ptr = TYPE_PTR_P (type);
+ const bool is_ptr = TYPE_PTR_P (type);
if (is_ptr || TYPE_REF_P (type))
{
tree core = TREE_TYPE (type);
if (is_ptr && VOID_TYPE_P (core))
/* OK */;
- else if (!complete_type_or_else (core, from))
- return 0;
+ else if (!complete_type_or_maybe_complain (core, from, complain))
+ return false;
}
- return 1;
+ return true;
}
/* If IS_THROW is true return truth-value if T is an expression admissible
@@ -846,13 +844,14 @@ complete_ptr_ref_or_void_ptr_p (tree type, tree from)
for its type plus rvalue reference type is also not admissible. */
static bool
-is_admissible_throw_operand_or_catch_parameter (tree t, bool is_throw)
+is_admissible_throw_operand_or_catch_parameter (tree t, bool is_throw,
+ tsubst_flags_t complain)
{
tree expr = is_throw ? t : NULL_TREE;
tree type = TREE_TYPE (t);
/* C++11 [except.handle] The exception-declaration shall not denote
- an incomplete type, an abstract class type, or an rvalue reference
+ an incomplete type, an abstract class type, or an rvalue reference
type. */
/* 15.1/4 [...] The type of the throw-expression shall not be an
@@ -862,7
Re: [PATCH] c++/modules: use optimized crc32 from zlib
On 2/12/24 16:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK.
-- >8 --
The current implementation of bytes::calc_crc computes the checksum one
byte at a time, and turns out to be quite slow, taking 5% and 15% of
time compiling and streaming in the std module respectively. We have
a crc32_unsigned routine that handles 4 bytes at a time which could
speed up this hot function, but we also have a bundled zlib with highly
optimized crc routines that can handle up to 32 bytes at a time.
So this patch makes us use zlib's crc32 in this hot code path.
According to some perf experiments this reduces the overhead of calc_crc
from 15% of total time to 3% when streaming in the std module.
gcc/cp/ChangeLog:
* Make-lang.in (CFLAGS-cp/module.o): Add $(ZLIBINC).
* module.cc: Include .
(bytes::calc_crc): Use crc32 from zlib.
(bytes_out::set_crc): Use crc32_combine from zlib.
---
gcc/cp/Make-lang.in | 2 +-
gcc/cp/module.cc| 8 +++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 630db41d87e..f153891a1ef 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -55,7 +55,7 @@ c++.serial = cc1plus$(exeext)
CFLAGS-cp/g++spec.o += $(DRIVER_DEFINES)
CFLAGS-cp/module.o += -DHOST_MACHINE=\"$(host)\" \
- -DTARGET_MACHINE=\"$(target)\"
+ -DTARGET_MACHINE=\"$(target)\" $(ZLIBINC)
# In non-release builds, use a date-related module version.
ifneq ($(DEVPHASE_c),)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 86e43aee542..c94f4a257de 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -233,6 +233,7 @@ Classes used:
/* This TU doesn't need or want to see the networking. */
#define CODY_NETWORKING 0
#include "mapper-client.h"
+#include // for crc32, crc32_combine
#if 0 // 1 for testing no mmap
#define MAPPED_READING 0
@@ -487,10 +488,7 @@ protected:
unsigned
bytes::calc_crc (unsigned l) const
{
- unsigned crc = 0;
- for (size_t ix = 4; ix < l; ix++)
-crc = crc32_byte (crc, buffer[ix]);
- return crc;
+ return crc32 (0, (unsigned char *)buffer + 4, l - 4);
}
class elf_in;
@@ -717,7 +715,7 @@ bytes_out::set_crc (unsigned *crc_ptr)
unsigned crc = calc_crc (pos);
unsigned accum = *crc_ptr;
/* Only mix the existing *CRC_PTR if it is non-zero. */
- accum = accum ? crc32_unsigned (accum, crc) : crc;
+ accum = accum ? crc32_combine (accum, crc, pos - 4) : crc;
*crc_ptr = accum;
/* Buffer will be sufficiently aligned. */
[Bug libfortran/113897] Consecutive tab edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-13 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- Adding to my list, but I do not see any priority needed for it.
[Bug libfortran/113897] New: Consecutive tab edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 Bug ID: 113897 Summary: Consecutive tab edits in format are not processed correctly. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- This issue found while working on pr109358. program tabs implicit none integer :: fd open(newunit=fd, file="test.txt", form="formatted") write(fd, "(a)") "12345678901234567890123456789" write(fd, "(i4, t25, t2, i4.4)") 1234, 0123 close(fd) end program tabs With gfortran gcc 10.4.1 20230121 (GCC) $ gfc10 -static -o tabs.x tabs.f90 $ ./tabs.x $ cat test.txt 12345678901234567890123456789 12340123 It seems to me this should be: 10123 Even though it is nonsensical to do this, it probably is valid. I will check the standards.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:d85a658402d5433ff223ce8f4e70174ed8a20428 commit r13-8322-gd85a658402d5433ff223ce8f4e70174ed8a20428 Author: Jerry DeLisle Date: Mon Feb 12 13:12:08 2024 -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. gcc/testsuite/ChangeLog: * gfortran.dg/pr109358.f90: New test. (cherry picked from commit 153ce7a78edbe339fa0b1cd314dea0554f59faf0)
[PATCH] aarch64: Use vec_perm_indices::new_shrunk_vector in aarch64_evpc_reencode
While working on PERM related stuff, I can across that aarch64_evpc_reencode
was manually figuring out if we shrink the perm indices instead of
using vec_perm_indices::new_shrunk_vector; shrunk was added after reencode
was added.
Built and tested for aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/113822
* config/aarch64/aarch64.cc (aarch64_evpc_reencode): Use
vec_perm_indices::new_shrunk_vector instead of manually
going through the indices.
Signed-off-by: Andrew Pinski
---
gcc/config/aarch64/aarch64.cc | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 32eae49d4e9..f4ed8b86532 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -25431,7 +25431,6 @@ static bool
aarch64_evpc_reencode (struct expand_vec_perm_d *d)
{
expand_vec_perm_d newd;
- unsigned HOST_WIDE_INT nelt;
if (d->vec_flags != VEC_ADVSIMD)
return false;
@@ -25446,24 +25445,10 @@ aarch64_evpc_reencode (struct expand_vec_perm_d *d)
if (new_mode == word_mode)
return false;
- /* to_constant is safe since this routine is specific to Advanced SIMD
- vectors. */
- nelt = d->perm.length ().to_constant ();
-
- vec_perm_builder newpermconst;
- newpermconst.new_vector (nelt / 2, nelt / 2, 1);
+ vec_perm_indices newpermindices;
- /* Convert the perm constant if we can. Require even, odd as the pairs. */
- for (unsigned int i = 0; i < nelt; i += 2)
-{
- poly_int64 elt0 = d->perm[i];
- poly_int64 elt1 = d->perm[i + 1];
- poly_int64 newelt;
- if (!multiple_p (elt0, 2, ) || maybe_ne (elt0 + 1, elt1))
- return false;
- newpermconst.quick_push (newelt.to_constant ());
-}
- newpermconst.finalize ();
+ if (!newpermindices.new_shrunk_vector (d->perm, 2))
+return false;
newd.vmode = new_mode;
newd.vec_flags = VEC_ADVSIMD;
@@ -25475,7 +25460,8 @@ aarch64_evpc_reencode (struct expand_vec_perm_d *d)
newd.testing_p = d->testing_p;
newd.one_vector_p = d->one_vector_p;
- newd.perm.new_vector (newpermconst, newd.one_vector_p ? 1 : 2, nelt / 2);
+ newd.perm.new_vector (newpermindices.encoding (), newd.one_vector_p ? 1 : 2,
+ newpermindices.nelts_per_input ());
return aarch64_expand_vec_perm_const_1 ();
}
--
2.43.0
[Bug lto/110710] LTO linker on Windows creates an invalid Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710 Amyspark changed: What|Removed |Added CC||amy at amyspark dot me --- Comment #6 from Amyspark --- This still happens in GCC 13.2, and breaks standalone usage of GCC outside of a MSYS2 (or similar) shell. See my report (I did it way before finding this bug, will cross link now): https://github.com/StephanTLavavej/mingw-distro/issues/102
[pushed] diagnostics: unbreak 'make gcc.pot'
On Fri, 2024-02-09 at 16:53 +, Joseph Myers wrote: > On Fri, 1 Dec 2023, David Malcolm wrote: > > * diagnostic-core.h (emit_diagnostic_valist): New overload > decl. > > This has broken regeneration of gcc.pot (overloads can't have the > message > extracted for translation in different argument positions). > > 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 > > See commit 6c8e584430bc5dc01b4438f3c38a2a10fcba7685 for previous > fixes for > this involving the same function, or > 40fecdd62f7d293a214dd71b81de5e0f1099bba7 and > db30e21cbff7b9b2acd13ab83e25e3bf52f9696f for older fixes for similar > issues. Sorry about this; should be fixed by the following patch. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Verified that "make gcc.pot" succeeds with the patch. Pushed to trunk as r14-8946-gb753ef8f0c1d9c. 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. See also r10-6297-g6c8e584430bc5d for previous fixes for this involving the same function, or r5-6946-g40fecdd62f7d29 and r5-6959-gdb30e21cbff7b9 for older fixes for similar issues. 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. gcc/ChangeLog: * diagnostic-core.h (emit_diagnostic_valist): Rename overload to... (emit_diagnostic_valist_meta): ...this. * diagnostic.cc (emit_diagnostic_valist): Likewise, to... (emit_diagnostic_valist_meta): ...this. Signed-off-by: David Malcolm --- gcc/analyzer/pending-diagnostic.cc | 16 gcc/diagnostic-core.h | 12 ++-- gcc/diagnostic.cc | 10 +- 3 files changed, 19 insertions(+), 19 deletions(-) diff --git a/gcc/analyzer/pending-diagnostic.cc b/gcc/analyzer/pending-diagnostic.cc index e49aaa5a6d9..b2961c21bfc 100644 --- a/gcc/analyzer/pending-diagnostic.cc +++ b/gcc/analyzer/pending-diagnostic.cc @@ -129,10 +129,10 @@ diagnostic_emission_context::warn (const char *gmsgid, ...) auto_diagnostic_group d; va_list ap; va_start (ap, gmsgid); - const bool result = emit_diagnostic_valist (DK_WARNING, - _rich_loc, _metadata, - pd.get_controlling_option (), - gmsgid, ); + const bool result = emit_diagnostic_valist_meta (DK_WARNING, + _rich_loc, _metadata, + pd.get_controlling_option (), + gmsgid, ); va_end (ap); return result; } @@ -147,10 +147,10 @@ diagnostic_emission_context::inform (const char *gmsgid, ...) auto_diagnostic_group d; va_list ap; va_start (ap, gmsgid); - emit_diagnostic_valist (DK_NOTE, - _rich_loc, _metadata, - pd.get_controlling_option (), - gmsgid, ); + emit_diagnostic_valist_meta (DK_NOTE, + _rich_loc, _metadata, + pd.get_controlling_option (), + gmsgid, ); va_end (ap); } diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h index 7918bd7d4a2..f5e1e500dc3 100644 --- a/gcc/diagnostic-core.h +++ b/gcc/diagnostic-core.h @@ -123,12 +123,12 @@ extern bool emit_diagnostic (diagnostic_t, rich_location *, int, const char *, ...) ATTRIBUTE_GCC_DIAG(4,5); extern bool emit_diagnostic_valist (diagnostic_t, location_t, int, const char *, va_list *) ATTRIBUTE_GCC_DIAG (4,0); -extern bool emit_diagnostic_valist (diagnostic_t, - rich_location *, - const diagnostic_metadata *, - int, - const char *, - va_list *) ATTRIBUTE_GCC_DIAG (5,0); +extern bool emit_diagnostic_valist_meta (diagnostic_t, +rich_location *, +const diagnostic_metadata *, +int, +
[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 --- Comment #14 from Marek Polacek --- My current patch appears to handle that correctly: $ ./cc1plus -quiet q.C -pedantic-errors -std=c++98 -Wno-error=extra-semi q.C:3:3: warning: extra ‘;’ outside of a function only allowed in C++11 [-Wextra-semi] 3 | };; | ^ | - I'll add a test for that combination.
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 --- Comment #13 from Harald van Dijk --- (In reply to Marek Polacek from comment #12) > Thank for your comment. In the end I went with > > -std=c++03 -pedantic-errors -Wextra-semi -> warnings > -std=c++03 -pedantic -Wextra-semi -> warnings (not pedwarn) > > based on the principle that a more specific option overrides a more general > option. This is also what clang++ does. Granted, -Wvla in C doesn't behave > like that... That also makes sense. The more specific option overriding a more general option is also the reasoning why I expect no error with -pedantic-errors -Wno-error=extra-semi.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #38 from Jerry DeLisle --- Fixed on trunk and 13
[Bug fortran/85836] [meta-bug] Fortran 2018 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836 Bug 85836 depends on bug 111022, which changed state. Bug 111022 Summary: ES0.0E0 format gave ES0.dE0 output with d too high. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #37 from GCC Commits --- The releases/gcc-13 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:fbe5e908de76aa240bbcd2f144c156eccc863604 commit r13-8321-gfbe5e908de76aa240bbcd2f144c156eccc863604 Author: Jerry DeLisle Date: Fri Feb 2 18:12:33 2024 -0800 libgfortran: EN0.0E0 and ES0.0E0 format editing. F2018 and F2023 standards added zero width exponents. This required additional special handing in the process of building formatted floating point strings. G formatting uses either F or E formatting as documented in write_float.def comments. This logic changes the format token from FMT_G to FMT_F or FMT_E. The new formatting requirements interfere with this process when a FMT_G float string is being built. To avoid this, a new component called 'pushed' is added to the fnode structure to save this condition. The 'pushed' condition is then used to bypass portions of the new ES,E,EN, and D formatting, falling through to the existing default formatting which is retained. libgfortran/ChangeLog: PR libfortran/111022 * io/format.c (get_fnode): Update initialization of fnode. (parse_format_list): Initialization. * io/format.h (struct fnode): Added the new 'pushed' component. * io/write.c (select_buffer): Whitespace. (write_real): Whitespace. (write_real_w0): Adjust logic for the d == 0 condition. * io/write_float.def (determine_precision): Whitespace. (build_float_string): Calculate width of ..E0 exponents and adjust logic accordingly. (build_infnan_string): Whitespace. (CALCULATE_EXP): Whitespace. (quadmath_snprintf): Whitespace. (determine_en_precision): Whitespace. gcc/testsuite/ChangeLog: PR libfortran/111022 * gfortran.dg/fmt_error_10.f: Show D+0 exponent. * gfortran.dg/pr96436_4.f90: Show E+0 exponent. * gfortran.dg/pr96436_5.f90: Show E+0 exponent. * gfortran.dg/pr111022.f90: New test. (cherry picked from commit d436e8e70dacd9c06247bb56d0abeded8fcb4242)
Re: Unreviewed c++ and libgomp testsuite patches
> On Feb 12, 2024, at 5:27 AM, Rainer Orth > wrote: > > The following patches have remained unreviewed for a week or more: > > testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706] >https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644842.html Jason commented. > Probably needs a C++ maintainer, although I've Cc'ed the testcase author > for good measure. > > libgomp: testsuite: Don't XPASS libgomp.c/alloc-pinned-1.c etc. on > non-Linux targets [PR113448] > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644967.html I'm fine with this as well. Ok.
[Bug tree-optimization/113896] [12 Regression] Assigning array elements in the wrong order after floating point optimization since r12-8841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896 Andrew Pinski changed: What|Removed |Added Summary|[12 Regression] Assigning |[12 Regression] Assigning |array elements in the wrong |array elements in the wrong |order after floating point |order after floating point |optimization|optimization since r12-8841 --- Comment #1 from Andrew Pinski --- r12-8841-gfe7d74313736b8
Re: [PATCH 2/2] c++/modules: ICE with modular fmtlib
On 2/10/24 13:37, Patrick Palka wrote:
On Sat, 10 Feb 2024, Jason Merrill wrote:
On 2/9/24 17:11, Patrick Palka wrote:
On Fri, 9 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
I'll try to reduce and add testcases overnight for these separate bugs
before pushing.
-- >8 --
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 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.
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_specializations): Use
STRIP_TEMPLATE consistently.
(get_originating_module_decl): Handle class-scope CONST_DECL.
---
gcc/cp/module.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 3c2fef0e3f4..659fa03dae1 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13248,7 +13248,7 @@ depset::hash::add_specializations (bool decl_p)
if (use_tpl == 1)
/* Implicit instantiations only walked if we reach them. */
needs_reaching = true;
- else if (!DECL_LANG_SPECIFIC (spec)
+ else if (!DECL_LANG_SPECIFIC (STRIP_TEMPLATE (spec))
|| !DECL_MODULE_PURVIEW_P (STRIP_TEMPLATE (spec)))
/* Likewise, GMF explicit or partial specializations. */
needs_reaching = true;
@@ -18708,7 +18708,8 @@ get_originating_module_decl (tree decl)
&& (TREE_CODE (DECL_CONTEXT (decl)) == ENUMERAL_TYPE))
decl = TYPE_NAME (DECL_CONTEXT (decl));
else if (TREE_CODE (decl) == FIELD_DECL
- || TREE_CODE (decl) == USING_DECL)
+ || TREE_CODE (decl) == USING_DECL
+ || TREE_CODE (decl) == CONST_DECL)
On second thought maybe we should test for CONST_DECL_USING_P (decl)
specifically. In other contexts a CONST_DECL could be a template
parameter, so using CONST_DECL_USING_P makes this code more readable
arguably.
That makes sense.
Like so? Now with reduced testcases:
OK.
-- >8 --
Subject: [PATCH] c++/modules: ICEs with modular fmtlib
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:
* gcc/testsuite/g++.dg/modules/friend-6_a.C: New test.
* gcc/testsuite/g++.dg/modules/using-enum-3_a.C: New test.
* gcc/testsuite/g++.dg/modules/using-enum-3_b.C: New test.
---
gcc/cp/module.cc | 5 +++--
gcc/testsuite/g++.dg/modules/friend-6_a.C | 11 +++
gcc/testsuite/g++.dg/modules/using-enum-3_a.C | 10 ++
gcc/testsuite/g++.dg/modules/using-enum-3_b.C | 5 +
4 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/friend-6_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/using-enum-3_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/using-enum-3_b.C
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 3c2fef0e3f4..86e43aee542 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13248,7 +13248,7 @@ depset::hash::add_specializations (bool decl_p)
if (use_tpl == 1)
/* Implicit instantiations only walked if we reach them. */
needs_reaching = true;
- else if (!DECL_LANG_SPECIFIC (spec)
+ else if (!DECL_LANG_SPECIFIC (STRIP_TEMPLATE (spec))
|| !DECL_MODULE_PURVIEW_P (STRIP_TEMPLATE (spec)))
/* Likewise, GMF explicit or partial specializations. */
needs_reaching = true;
@@ -18708,7 +18708,8 @@ get_originating_module_decl (tree decl)
&& (TREE_CODE (DECL_CONTEXT (decl)) == ENUMERAL_TYPE))
decl = TYPE_NAME (DECL_CONTEXT (decl));
else if (TREE_CODE (decl) == FIELD_DECL
- || TREE_CODE (decl) == USING_DECL)
+ || TREE_CODE (decl) == USING_DECL
+ || CONST_DECL_USING_P (decl))
{
decl = DECL_CONTEXT (decl);
if (TREE_CODE (decl) != FUNCTION_DECL)
diff --git a/gcc/testsuite/g++.dg/modules/friend-6_a.C
b/gcc/testsuite/g++.dg/modules/friend-6_a.C
new file mode 100644
index 000..3b3d714b3f3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/friend-6_a.C
@@ -0,0 +1,11 @@
+// { dg-additional-options "-fmodules-ts -Wno-pedantic" }
+// { dg-module-cmi friend_6 }
+
+module;
+# 1 "" 1
+template struct Trans_NS___cxx11_basic_string {
+ template friend class basic_stringbuf;
+};
+template struct Trans_NS___cxx11_basic_string;
+# 6 "" 2
+export module friend_6;
diff --git a/gcc/testsuite/g++.dg/modules/using-enum-3_a.C
b/gcc/testsuite/g++.dg/modules/using-enum-3_a.C
new file mode
[Bug tree-optimization/113896] [12 Regression] Assigning array elements in the wrong order after floating point optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4 Summary|Assigning array elements in |[12 Regression] Assigning |the wrong order after |array elements in the wrong |floating point optimization |order after floating point ||optimization Keywords||wrong-code Component|c++ |tree-optimization Known to fail||12.3.0 Known to work||11.4.0, 12.1.0, 12.2.0
[Bug c++/113896] New: Assigning array elements in the wrong order after floating point optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Bug ID: 113896
Summary: Assigning array elements in the wrong order after
floating point optimization
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noobie-iv at mail dot ru
Target Milestone: ---
Created attachment 57404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57404=edit
Test program and build_and_run script
/* file: f.cpp */
extern double a1; // 1.0
extern double a2; // 1.0
void f(double K[2], bool b)
{
double A[] = {
b ? a1 : a2,
0,
0,
0
};
double sum{};
for(double a : A) sum += a;
for(double& a : A) a /= sum;
if (b) {
K[0] = A[0]; // 1.0
K[1] = A[1]; // 0.0
} else {
K[0] = A[0] + A[1];
}
}
/* file: main.cpp */
#include
double a1 = 1.0;
double a2 = 1.0;
void f(double K[2], bool b);
int main()
{
double K[2]{};
f(K, true);
std::cout << K[0] << "\t" << K[1] << "\n";
}
Bug: Returns different results when compiled with different optimization
settings:
g++ -O2 -ffast-math f.cpp main.cpp -o good
g++ -O3 -ffast-math f.cpp main.cpp -o bad
./good outputs "1 0"
./bad outputs "0 1"
The bug is reproduced in systems:
* Fedora-37-1.7 x64 with latest gcc autoupdate (12.3.1 20230508)
* Debian-12.2.0 x64 with gcc-12.3.1 build from sources
In the gcc-12 branch:
* Last good commit: d127348d7711e148e5ddd205a8c3409b37fae64c (12.2.1 20221017)
* First bad commit: fe7d74313736b8e1c30812bc49419f419bdf1c53 (12.2.1 20221017)
* Last tested bad commit: 4ced4ca95001f1583623c801c9c3642224a2c4f0 (12.3.1
20240210)
In the gcc-13 branch - There is no bug:
* Last tested good commit: c891d8dc23e1a46ad9f3e757d09e57b500d40044 (13.2.0)
In the gcc-14 branch - There is no bug:
* Last tested good commit: cff174fabd6c980c09aee95db1d9d5c22421761f (14.0.1
20240210)
Note: Function f() is a simplified version of the
XSpline::linearCombinationFor() function from the scantailor-experimental
project:
https://github.com/ImageProcessing-ElectronicPublications/scantailor-experimental/blob/main/src/math/XSpline.cpp
Now the bug has been temporarily resolved by declaring array A volatile.
[Bug target/113822] aarch64_evpc_reencode could/should use new_shrunk_vector instead of manually doing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine, I have a patch which I will submit in a few hours after full testing.
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 --- Comment #12 from Marek Polacek --- Thank for your comment. In the end I went with -std=c++03 -pedantic-errors -Wextra-semi -> warnings -std=c++03 -pedantic -Wextra-semi -> warnings (not pedwarn) based on the principle that a more specific option overrides a more general option. This is also what clang++ does. Granted, -Wvla in C doesn't behave like that...
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #14 from John Paul Adrian Glaubitz --- The posix_spawn() issue on sparc64 is explained in more detail, including a reproducer, here: https://lore.kernel.org/sparclinux/3ae4130c-c5aa-428e-b819-44cf2daf2...@mkarcher.dialup.fu-berlin.de/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #14 from John Paul Adrian Glaubitz --- The posix_spawn() issue on sparc64 is explained in more detail, including a reproducer, here: https://lore.kernel.org/sparclinux/3ae4130c-c5aa-428e-b819-44cf2daf2...@mkarcher.dialup.fu-berlin.de/
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #11 from Harald van Dijk --- (In reply to Marek Polacek from comment #8) > -std=c++03 -pedantic-errors -Wextra-semi -> errors (?) Speaking as a user: that makes sense to me, but I would also expect: -std=c++03 -pedantic-errors -Wno-error=extra-semi -> warnings
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #12 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:153ce7a78edbe339fa0b1cd314dea0554f59faf0 commit r14-8944-g153ce7a78edbe339fa0b1cd314dea0554f59faf0 Author: Jerry DeLisle Date: Mon Feb 12 13:12:08 2024 -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. gcc/testsuite/ChangeLog: * gfortran.dg/pr109358.f90: New test.
PING Re: [PATCH RFA] gdbhooks: regex syntax error
Ping
On 2/6/24 17:07, Jason Merrill wrote:
Briefly tested that break-on-pass completion works. Oddly, it also works
without the patch, but the fix still seems worthwhile. OK for trunk?
-- 8< --
Recent python complains about this pattern with
SyntaxWarning: invalid escape sequence '\s'
because \s in a regular string just means 's'; for it to mean whitespace,
you need \\ or for the pattern to be a raw string.
gcc/ChangeLog:
* gdbhooks.py: Fix regex syntax.
---
gcc/gdbhooks.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index 3fa62652c61..92e38880a70 100644
--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhooks.py
@@ -642,7 +642,7 @@ class PassNames:
self.names = []
with open(os.path.join(srcdir, 'passes.def')) as f:
for line in f:
-m = re.match('\s*NEXT_PASS \(([^,]+).*\);', line)
+m = re.match(r'\s*NEXT_PASS \(([^,]+).*\);', line)
if m:
self.names.append(m.group(1))
base-commit: c5d34912ad576be1ef19be92f7eabde54b9089eb
[Bug libstdc++/113294] constexpr error from accessing inactive union member in basic_string after move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:065dddc6e07a917c57c7955db13b1fe77abbcabc commit r14-8943-g065dddc6e07a917c57c7955db13b1fe77abbcabc Author: Paul Keir Date: Mon Feb 12 18:15:49 2024 + 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 Reviewed-by: Patrick Palka Reviewed-by: Jonathan Wakely
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895 Andrew Pinski changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- I am 99% sure this was caused by r14-8929-g938a419182f8c4 as it was not reproducible in r14-8924 .
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |tree-optimization Summary|ice in in |[14 Regression] ice in in |copy_reference_ops_from_ref |copy_reference_ops_from_ref |, at tree-ssa-sccvn.cc:1144 |, at tree-ssa-sccvn.cc:1144 Target Milestone|--- |14.0
Re: [PATCH] libstdc++: Fix constexpr basic_string union member [PR113294]
On Mon, 12 Feb 2024 at 22:17, Patrick Palka wrote:
> On Mon, 12 Feb 2024, Paul Keir wrote:
>
> > 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.
> >
> > Running `make check
> RUNTESTFLAGS="conformance.exp=21_strings/basic_string/*"` on
> x86_64-pc-linux-gnu gave unchanged summary results (# of expected passes
> 570 # of expected failures 4 # of unsupported tests 4).
> >
> > I don't have write access.
> >
> > Signed-off-by: Paul Keir
>
> LGTM! A ChangeLog entry is missing from the commit message,
> so here's one that we can use for this commit:
>
> 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.
>
The patch is OK for trunk and gcc-13 with that commit msg. Patrick, could
you push it for Paul?
Thank you both.
> >
> > diff --git a/libstdc++-v3/include/bits/basic_string.h
> b/libstdc++-v3/include/bits/basic_string.h
> > index 43efc99bea9..8a695a494ef 100644
> > --- a/libstdc++-v3/include/bits/basic_string.h
> > +++ b/libstdc++-v3/include/bits/basic_string.h
> > @@ -909,7 +909,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> > __str._M_capacity(__capacity);
> > }
> > else
> > - __str._M_data(__str._M_local_buf);
> > + __str._M_data(__str._M_use_local_data());
> > }
> > else // Need to do a deep copy
> > assign(__str);
> > diff --git
> a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> > index 0e28a6d4487..ad7548f3236 100644
> > ---
> a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> > +++
> b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> > @@ -50,3 +50,16 @@ test_erasure()
> > }
> >
> > static_assert( test_erasure() );
> > +
> > +constexpr bool
> > +test_move()
> > +{
> > + std::string s1;
> > + std::string s2 = "1234567890123456"; // 16 chars: more than
> _S_local_capacity
> > + s1 = std::move(s2);
> > + VERIFY( s1 == "1234567890123456" );
> > +
> > + return true;
> > +}
> > +
> > +static_assert( test_move() );
> > --
> >
> >
> > Please consider the environment and think before you print.
> >
> > The University of the West of Scotland is a registered Scottish charity.
> Charity number SC002520.
> >
> > This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any
> attachment and all copies and inform the sender.
> >
> > Please note that any views or opinions presented in this email are
> solely those of the author and do not necessarily represent those of the
> University of the West of Scotland.
> >
> > As a public body, the University of the West of Scotland may be required
> to make available emails as well as other written forms of information as a
> result of a request made under the Freedom of Information (Scotland) Act
> 2002.
> >
> >
>
>
[Bug c/113895] New: ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
Bug ID: 113895
Summary: ice in in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1144
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C source code:
int main_i;
void transparent_crc();
#pragma pack(1)
struct {
signed : 17;
signed : 6;
unsigned : 13;
unsigned f6 : 12
} g_20[];
void main() { transparent_crc(g_20[main_i].f6); }
when compiled by recent gcc, does this:
cvise $ ~/gcc/results/bin/gcc -c -O1 bug1011.c
bug1011.c:9:1: warning: no semicolon at end of struct or union
9 | } g_20[];
| ^
bug1011.c:9:3: warning: array ‘g_20’ assumed to have one element
9 | } g_20[];
| ^~~~
during GIMPLE pass: fre
bug1011.c: In function ‘main’:
bug1011.c:10:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1144
10 | void main() { transparent_crc(g_20[main_i].f6); }
| ^~~~
0x10e922a copy_reference_ops_from_ref(tree_node*, vec*)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-ssa-sccvn.cc:1144
The bug first seems to appear sometime between g:48207a5f00d6ae7c
and g:39d989022dd0eacf.
Re: [PATCH] libstdc++: Fix constexpr basic_string union member [PR113294]
On Mon, 12 Feb 2024, Paul Keir wrote:
> 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.
>
> Running `make check RUNTESTFLAGS="conformance.exp=21_strings/basic_string/*"`
> on x86_64-pc-linux-gnu gave unchanged summary results (# of expected passes
> 570 # of expected failures 4 # of unsupported tests 4).
>
> I don't have write access.
>
> Signed-off-by: Paul Keir
LGTM! A ChangeLog entry is missing from the commit message,
so here's one that we can use for this commit:
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.
>
> diff --git a/libstdc++-v3/include/bits/basic_string.h
> b/libstdc++-v3/include/bits/basic_string.h
> index 43efc99bea9..8a695a494ef 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -909,7 +909,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> __str._M_capacity(__capacity);
> }
> else
> - __str._M_data(__str._M_local_buf);
> + __str._M_data(__str._M_use_local_data());
> }
> else // Need to do a deep copy
> assign(__str);
> diff --git
> a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> index 0e28a6d4487..ad7548f3236 100644
> --- a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> +++ b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
> @@ -50,3 +50,16 @@ test_erasure()
> }
>
> static_assert( test_erasure() );
> +
> +constexpr bool
> +test_move()
> +{
> + std::string s1;
> + std::string s2 = "1234567890123456"; // 16 chars: more than
> _S_local_capacity
> + s1 = std::move(s2);
> + VERIFY( s1 == "1234567890123456" );
> +
> + return true;
> +}
> +
> +static_assert( test_move() );
> --
>
>
> Please consider the environment and think before you print.
>
> The University of the West of Scotland is a registered Scottish charity.
> Charity number SC002520.
>
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential
> information and/or be subject to legal privilege. It should not be copied,
> disclosed to, retained or used by, any other party. If you are not an
> intended recipient then please promptly delete this e-mail and any attachment
> and all copies and inform the sender.
>
> Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the University
> of the West of Scotland.
>
> As a public body, the University of the West of Scotland may be required to
> make available emails as well as other written forms of information as a
> result of a request made under the Freedom of Information (Scotland) Act 2002.
>
>
Re: [patch, libgfortran] PR109358
Hi Jerry. Am 12.02.24 um 22:28 schrieb Jerry D: The attached patch fixes this PR by properly adjusting some variables When using stream io. See log below. New test case included. Regression tested on x86_64. OK for trunk and backport? the patch looks good to me. As it is simple and very local, feel free to backport at your discretion. Thanks for the patch! Harald Regards, Jerry ChangeLog: 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. libgfortran/ChangeLog: PR libgfortran/109358 * io/transfer.c (formatted_transfer_scalar_write): Adjust bytes_used and pos variable for stream access. gcc/testsuite/ChangeLog: PR libgfortran/109358 * gfortran.dg/pr109358.f90: New test.
[PATCH] c++/modules: use optimized crc32 from zlib
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
The current implementation of bytes::calc_crc computes the checksum one
byte at a time, and turns out to be quite slow, taking 5% and 15% of
time compiling and streaming in the std module respectively. We have
a crc32_unsigned routine that handles 4 bytes at a time which could
speed up this hot function, but we also have a bundled zlib with highly
optimized crc routines that can handle up to 32 bytes at a time.
So this patch makes us use zlib's crc32 in this hot code path.
According to some perf experiments this reduces the overhead of calc_crc
from 15% of total time to 3% when streaming in the std module.
gcc/cp/ChangeLog:
* Make-lang.in (CFLAGS-cp/module.o): Add $(ZLIBINC).
* module.cc: Include .
(bytes::calc_crc): Use crc32 from zlib.
(bytes_out::set_crc): Use crc32_combine from zlib.
---
gcc/cp/Make-lang.in | 2 +-
gcc/cp/module.cc| 8 +++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 630db41d87e..f153891a1ef 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -55,7 +55,7 @@ c++.serial = cc1plus$(exeext)
CFLAGS-cp/g++spec.o += $(DRIVER_DEFINES)
CFLAGS-cp/module.o += -DHOST_MACHINE=\"$(host)\" \
- -DTARGET_MACHINE=\"$(target)\"
+ -DTARGET_MACHINE=\"$(target)\" $(ZLIBINC)
# In non-release builds, use a date-related module version.
ifneq ($(DEVPHASE_c),)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 86e43aee542..c94f4a257de 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -233,6 +233,7 @@ Classes used:
/* This TU doesn't need or want to see the networking. */
#define CODY_NETWORKING 0
#include "mapper-client.h"
+#include // for crc32, crc32_combine
#if 0 // 1 for testing no mmap
#define MAPPED_READING 0
@@ -487,10 +488,7 @@ protected:
unsigned
bytes::calc_crc (unsigned l) const
{
- unsigned crc = 0;
- for (size_t ix = 4; ix < l; ix++)
-crc = crc32_byte (crc, buffer[ix]);
- return crc;
+ return crc32 (0, (unsigned char *)buffer + 4, l - 4);
}
class elf_in;
@@ -717,7 +715,7 @@ bytes_out::set_crc (unsigned *crc_ptr)
unsigned crc = calc_crc (pos);
unsigned accum = *crc_ptr;
/* Only mix the existing *CRC_PTR if it is non-zero. */
- accum = accum ? crc32_unsigned (accum, crc) : crc;
+ accum = accum ? crc32_combine (accum, crc, pos - 4) : crc;
*crc_ptr = accum;
/* Buffer will be sufficiently aligned. */
--
2.43.0.561.g235986be82
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 --- Comment #10 from Marek Polacek --- And we should also warn in C++98 with -Wc++11-extensions for an extra ';' outside of a function I suppose...
[patch, libgfortran] PR109358
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
Regards,
Jerry
ChangeLog:
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.
libgfortran/ChangeLog:
PR libgfortran/109358
* io/transfer.c (formatted_transfer_scalar_write): Adjust
bytes_used and pos variable for stream access.
gcc/testsuite/ChangeLog:
PR libgfortran/109358
* gfortran.dg/pr109358.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr109358.f90 b/gcc/testsuite/gfortran.dg/pr109358.f90
new file mode 100644
index 000..5013984095b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr109358.f90
@@ -0,0 +1,14 @@
+! { dg-do run }
+! PR109358, test that tabs during stream io are correct.
+program tabs
+ implicit none
+ integer :: fd
+ character(64) :: line
+ open(newunit=fd, file="otabs.txt", form="formatted", access="stream")
+ write(fd, "(i4, t40, i4, t20, i5.5)") 1234, , 67890
+ close(fd)
+ open(newunit=fd, file="otabs.txt", form="formatted")
+ read(fd,"(a)") line
+ close(fd, status='delete')
+ if (line .ne. "1234 67890 ") stop 10
+end program tabs
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 80b60dfeb9f..99ef96a9e7c 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2072,11 +2072,11 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
}
- bytes_used = dtp->u.p.current_unit->recl
- - dtp->u.p.current_unit->bytes_left;
-
if (is_stream_io(dtp))
- bytes_used = 0;
+ bytes_used = dtp->u.p.current_unit->fbuf->act;
+ else
+ bytes_used = dtp->u.p.current_unit->recl
+ - dtp->u.p.current_unit->bytes_left;
switch (t)
{
@@ -2452,7 +2452,11 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
p = ((char *) p) + size;
}
- pos = dtp->u.p.current_unit->recl - dtp->u.p.current_unit->bytes_left;
+ if (is_stream_io(dtp))
+ pos = dtp->u.p.current_unit->fbuf->act;
+ else
+ pos = dtp->u.p.current_unit->recl - dtp->u.p.current_unit->bytes_left;
+
dtp->u.p.max_pos = (dtp->u.p.max_pos > pos) ? dtp->u.p.max_pos : pos;
}
Re: [PATCH] testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706]
On 2/2/24 10:23, Rainer Orth wrote: c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++: FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr FAIL: c-c++-common/pr103798-2.c -std=gnu++20 scan-assembler-not memchr FAIL: c-c++-common/pr103798-2.c -std=gnu++98 scan-assembler-not memchr As H.J. analyzed in the PR, Solaris declares std::memchr, not memchr, which isn't treated as __builtin_memchr. The problem seems to be not the std::, but that the Solaris string.h declares const void *memchr(const void *, int, size_t); as specified by the C++ standard, while gcc expects the return type to be void* like in C. This looks like a GCC bug, not Solaris; I'd prefer to xfail the testcase rather than work around the compiler bug. Jason
[Bug fortran/113866] ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-February/060220.html
[PATCH] Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]
Dear all,
the attached patch fixes a mis-handling of optional dummy arguments
passed to optional dummy arguments of procedures with the bind(c)
attribute. When those procedures are expecting CFI descriptors,
there is no special treatment like a presence check necessary
that by default passes a NULL pointer as default.
The testcase tries to exercise various combinations of passing
assumed-length character between bind(c) and non-bind(c), which
apparently was insufficiently covered in the testsuite.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 87d1b973a4d6a561dc3f3a0c4c10f76d155fa000 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 12 Feb 2024 21:39:09 +0100
Subject: [PATCH] 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.
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_optional-2.f90: New test.
---
gcc/fortran/trans-expr.cc | 6 +-
.../gfortran.dg/bind_c_optional-2.f90 | 104 ++
2 files changed, 108 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/bind_c_optional-2.f90
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 67abca9f6ba..a0593b76f18 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7269,8 +7269,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
with an interface indicating an optional argument. When we call
an intrinsic subroutine, however, fsym is NULL, but we might still
have an optional argument, so we proceed to the substitution
- just in case. */
- if (e && (fsym == NULL || fsym->attr.optional))
+ just in case. Arguments passed to bind(c) procedures via CFI
+ descriptors are handled elsewhere. */
+ if (e && (fsym == NULL || fsym->attr.optional)
+ && !(sym->attr.is_bind_c && is_CFI_desc (fsym, NULL)))
{
/* If an optional argument is itself an optional dummy argument,
check its presence and substitute a null if absent. This is
diff --git a/gcc/testsuite/gfortran.dg/bind_c_optional-2.f90 b/gcc/testsuite/gfortran.dg/bind_c_optional-2.f90
new file mode 100644
index 000..b8b4c87775e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/bind_c_optional-2.f90
@@ -0,0 +1,104 @@
+! { dg-do run }
+! PR fortran/113866
+!
+! Check interoperability of assumed-length character (optional and
+! non-optional) dummies between bind(c) and non-bind(c) procedures
+
+module bindcchar
+ implicit none
+ integer, parameter :: n = 100, l = 10
+contains
+ subroutine bindc_optional (c2, c4) bind(c)
+character(*), optional :: c2, c4(n)
+! print *, c2(1:3)
+! print *, c4(5)(1:3)
+if (.not. present (c2) .or. .not. present (c4)) stop 8
+if (c2(1:3)/= "a23") stop 1
+if (c4(5)(1:3) /= "bcd") stop 2
+if (len (c2) /= l .or. len (c4) /= l) stop 81
+ end
+
+ subroutine bindc (c2, c4) bind(c)
+character(*) :: c2, c4(n)
+if (c2(1:3)/= "a23") stop 3
+if (c4(5)(1:3) /= "bcd") stop 4
+if (len (c2) /= l .or. len (c4) /= l) stop 82
+call bindc_optional (c2, c4)
+ end
+
+ subroutine not_bindc_optional (c1, c3)
+character(*), optional :: c1, c3(n)
+if (.not. present (c1) .or. .not. present (c3)) stop 5
+call bindc_optional (c1, c3)
+call bindc (c1, c3)
+if (len (c1) /= l .or. len (c3) /= l) stop 83
+ end
+
+ subroutine not_bindc_optional_deferred (c5, c6)
+character(:), allocatable, optional :: c5, c6(:)
+if (.not. present (c5) .or. .not. present (c6)) stop 6
+call not_bindc_optional (c5, c6)
+call bindc_optional (c5, c6)
+call bindc (c5, c6)
+if (len (c5) /= l .or. len (c6) /= l) stop 84
+ end
+
+ subroutine not_bindc_optional2 (c7, c8)
+character(*), optional :: c7, c8(:)
+if (.not. present (c7) .or. .not. present (c8)) stop 7
+call bindc_optional (c7, c8)
+call bindc (c7, c8)
+if (len (c7) /= l .or. len (c8) /= l) stop 85
+ end
+
+ subroutine bindc_optional2 (c2, c4) bind(c)
+character(*), optional :: c2, c4(n)
+if (.not. present (c2) .or. .not. present (c4)) stop 8
+if (c2(1:3)/= "a23") stop 9
+if (c4(5)(1:3) /= "bcd") stop 10
+call bindc_optional (c2, c4)
+call not_bindc_optional (c2, c4)
+if (len (c2) /= l .or. len (c4) /= l) stop 86
+ end
+
+ subroutine bindc_optional_missing (c1, c2, c3, c4, c5) bind(c)
+character(*), optional :: c1, c2(n), c3(:), c4(..), c5(*)
+if (present (c1)) stop 11
+if (present (c2)) stop 12
+if (present (c3)) stop 13
+if (present (c4)) stop 14
+if (present (c5)) stop 15
+ end
+
+ subroutine non_bindc_optional_missing (c1, c2, c3, c4,
[Bug tree-optimization/113894] New: `(x ^ (-CMP)) + CMP` -> `CMP ? -x : x`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113894
Bug ID: 113894
Summary: `(x ^ (-CMP)) + CMP` -> `CMP ? -x : x`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int f(int *x, int *y)
{
for(int i = 0 ; i < 1024; i++) {
int c = (y[i] == 123);
x[i] = (x[i] ^ -c) + c; // a ^ [0,-1] + [0,1]
}
}
int fa(int *x, int *y)
{
for(int i = 0 ; i < 1024; i++) {
int c = -(y[i] == 123);
x[i] = (x[i] ^ c) - c; // a ^ [0, -1] - [0,-1]
}
}
int f1(int *x, int *y)
{
for(int i = 0 ; i < 1024; i++) {
int c = y[i] == 123;
x[i] = c ? -x[i] : x[i];
}
}
```
These all should be optimized to f1.
When the CMP is `(x[i] <0)`, this should be optimized into ABS.
[Bug ada/113893] New: Finalization exception issue with anonymous access object.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893
Bug ID: 113893
Summary: Finalization exception issue with anonymous access
object.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: p.p11 at orange dot fr
CC: dkm at gcc dot gnu.org
Target Milestone: ---
Created attachment 57403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57403=edit
Reproducer.
In the source code, two procedures: Test01 which uses Ada.Finalization and
Test02 which doesn't.
When executing only Test01, the Finalize calls of 2 objects and 2 anonymous
access objects seem correct:
overriding procedure Finalize (Object : in out Container) is
begin
Ada.Text_IO.Put_Line ("Current:" & Image (Object.Data));
end Finalize;
$ ./bin/test_20210208_fin
Test01:
Value: 2.64000E+01
Current: 8.8E+00
Current: 2.64000E+01
Current: 6.6E+00
Current: 7.7E+00
When executing Test01 then Test02, all the Finalize calls aren't displayed but
an exception occurs:
$ ./bin/test_20210208_fin
Test01:
Value: 2.64000E+01
Current: 8.8E+00
Current: 2.64000E+01
Test02:
Value: 2.64000E+01
Execution of ./bin/test_20210208_fin terminated by unhandled exception
raised CONSTRAINT_ERROR : erroneous memory access
I understand the compiler warning:
test_20210208_fin.adb:29:09: warning: object designated by anonymous access
object might not be finalized until its enclosing library unit goes out of
scope [enabled by default]
But, what could be wrong with the exception?
(Full code in attachment)
Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)
> Believe it or not, even though I have re-worked the internals of the > lattices completely, the array itself is older than my involvement with > GCC (or at least with ipa-cp.c ;-). > > So it being an array and not a vector is historical coincidence, as far > as I am concerned :-). But that may be the reason, or because vector > macros at that time looked scary, or perhaps the initialization by > XCNEWVEC zeroing everything out was considered attractive (I kind of > like that but constructors would probably be cleaner), I don't know. If your class is no longer a POD, then the clearing before construcion is dead and GCC may optimize it out. So fixing this may solve some surprised in foreseable future when we will try to compile older GCC's with newer ones. Honza > > Martin
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #36 from Jerry DeLisle --- I was looking for my damnit doll until I got to your last post. Is this one worthy of backport?
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #11 from Jerry DeLisle --- I am going to submit the attached patch to close this PR and open a new PR for the lingering multiple tab edits in a row. The problem there is we have a special case if we have different T, TL, and TR following each other, a nonsensical situation. However, we should handle it. It will require "looking ahead" or "looking back" in the format statement to know that this is happening.
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Marek Polacek --- Fixed on trunk, will backport to 13.
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I should be able to commit this. The patch looks good. I have one other thing to do in front of this.
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
On 2/10/24 07:30, Iain Sandoe wrote: On 10 Feb 2024, at 12:07, Jason Merrill wrote: On 2/10/24 05:46, Iain Sandoe wrote: On 9 Feb 2024, at 23:21, Iain Sandoe wrote: On 9 Feb 2024, at 10:56, Iain Sandoe wrote: On 8 Feb 2024, at 21:44, Jason Merrill wrote: On 2/8/24 12:55, Paolo Bonzini wrote: On 2/8/24 18:16, Jason Merrill wrote: Hmm. In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we want it to find the libgcc from the current stage. So it seems to me that what we want is for stage2+ LD_LIBRARY_PATH to include the TARGET_LIB_PATH from the previous stage. Something like the below, on top of the earlier patch. Does this make sense? Does it work on Darwin? Oops, that was broken, please consider this one instead: Yes, this one makes sense (and the current code would not work since it lacks the prev- prefix on TARGET_LIB_PATH). Indeed, that seems like evidence that the only element of TARGET_LIB_PATH that has been useful in HOST_EXPORTS is the prev- part of HOST_LIB_PATH_gcc. So, here's another patch that just includes that for post-stage1: <0001-build-drop-target-libs-from-LD_LIBRARY_PATH-PR105688.patch> Hmm this still fails for me with gnat1 being unable to find libgcc_s. It seems I have to add the PREV_HOST_LIB_PATH_gcc to HOST_LIB_PATH for it to succeed so, presumably, the post stage1 exports are not being forwarded to that build. I’ll try to analyze what exactly is failing. The fail is occurring in the target libada build; so, I suppose, one might say it’s reasonable that it requires this host path to be added to the target exports since it’s a host library used during target builds (or do folks expect the host exports to be made for target lib builds as well?) Appending the prev-gcc dirctory to the HOST_LIB_PATH fixes this Hmm this is still not right, in this case, I think it should actually be the “just built” directory; - if we have a tool that depends on host libraries (that happen to be also target ones), then those libraries have to be built before the tool so that they can be linked to it. (we specially copy libgcc* and the CRTs to gcc/ to allow for this case) - there is no prev-gcc in cross and —disable-bootstrap builds, but the tool will still be linked to the just-built host libraries (which will also be installed). So, I think we have to add HOST_LIB_PATH_gcc to HOST_LIB_PATH and HOST_PREV_LIB_PATH_gcc to POSTSTAGE1_HOST_EXPORTS (as per this patch). I don't follow. In a cross build, host libraries are a different architecture from target libraries, and certainly can't be linked into host binaries. In a disable-bootstrap build, even before my change TARGET_LIB_PATH isn't added to RPATH_ENVVAR, since that has been guarded with @if gcc-bootstrap. So in a bootstrap build, it shouldn't be needed for stage1 either. And for stage2, the one we need is from stage1, that matches the compiler we're building host tools with. What am I missing? nothing, I was off on a tangent about the cross/non-bootstrap, sorry about that. However, when doing target builds (the previous point) it seems we do have to make provision for gnat1 to find libgcc_s, and, at present, it seems that only the target exports are active. Ah, I see: When building target libraries in stage2, we run the stage2 compiler that needs the stage1 libgcc_s, but we don't have the HOST_EXPORTS because we're building target code, so we also need to get the libgcc path into TARGET_EXPORTS. Since TARGET_LIB_PATH is only added when gcc-bootstrap, I guess the previous libgcc is the only piece needed in TARGET_EXPORTS as well. So, how about this version of the patch? JasonFrom 843303e635ec55f512cfb97650032dc921f0c117 Mon Sep 17 00:00:00 2001 From: Jason Merrill Date: Wed, 24 Jan 2024 07:47:26 -0500 Subject: [PATCH] build: drop target libs from LD_LIBRARY_PATH [PR105688] To: gcc-patches@gcc.gnu.org The patch for PR22340 (r104978) moved the adding of TARGET_LIB_PATH to RPATH_ENVVAR from POSTSTAGE1_HOST_EXPORTS to HOST_EXPORTS, but didn't mention that in the ChangeLog; it also wasn't part of the patch that was sent to gcc-patches. I suspect it was included accidentally? It also causes PR105688 when rebuilding stage1: once the stage1 libstdc++ has been built, if calling the system gcc to build host code involves invoking any tool that links against libstdc++.so (gold, ccache) they get the just-built library instead of the system library they expect. Reverting that hunk of the change fixed my problem with bubblestrapping GCC 12 with ccache on a host with a newer system libstdc++. But I believe that adding TARGET_LIB_PATH to RPATH_ENVVAR is not needed for post-stage1 either. Including TARGET_LIB_PATH goes back to r37545, with the stated rationale of getting other C++
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:39d989022dd0eacf1a7b95b7b20621acbe717d70 commit r14-8942-g39d989022dd0eacf1a7b95b7b20621acbe717d70 Author: Marek Polacek Date: Mon Feb 12 14:53:24 2024 -0500 c++: ICE with reinterpret_cast and switch [PR113545] Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce to an INTEGER_CST, consider it non-constant. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-reinterpret3.C: Remove dg-ice.
[Bug tree-optimization/113849] wrong code with _BitInt() arithmetics at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113849 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug c++/113674] [11/12/13 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |[[attr]] causes |[[attr]] causes |internal compiler error: in |internal compiler error: in |decl_attributes, at |decl_attributes, at |attribs.cc:776 |attribs.cc:776 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/113849] wrong code with _BitInt() arithmetics at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113849 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9511b91c56f08b319b4a407608f85c96029ce7ce commit r14-8941-g9511b91c56f08b319b4a407608f85c96029ce7ce Author: Jakub Jelinek Date: Mon Feb 12 20:46:04 2024 +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 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. * gcc.dg/torture/bitint-58.c: New test.
[Bug c++/113674] [11/12/13/14 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b42e978f29b33071addff6d7bb8bcdb11d176606 commit r14-8940-gb42e978f29b33071addff6d7bb8bcdb11d176606 Author: Jakub Jelinek Date: Mon Feb 12 20:45:01 2024 +0100 attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674] 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 PR c++/113674 * attribs.cc (extract_attribute_substring): Remove. (lookup_scoped_attribute_spec): Don't call it. * c-c++-common/Wattributes-3.c: New test.
Re: [PATCH] lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849]
> Am 12.02.2024 um 18:47 schrieb Jakub Jelinek :
>
> Hi!
>
> 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.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok
Richard
> 2024-02-12 Jakub Jelinek
>
>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.
>
>* gcc.dg/torture/bitint-58.c: New test.
>
> --- gcc/gimple-lower-bitint.cc.jj2024-02-10 12:52:10.015925212 +0100
> +++ gcc/gimple-lower-bitint.cc2024-02-12 14:51:58.717472624 +0100
> @@ -1267,13 +1267,17 @@ bitint_large_huge::handle_cast (tree lhs
> the most significant limb is handled in straight
> line code. If m_var_msb (on left shifts) or
> if m_upwards_2limb * limb_prec is equal to
> - lhs precision that is not the case. */
> + lhs precision or if not m_upwards_2limb and lhs_type
> + has precision which is multiple of limb_prec that is
> + not the case. */
> || (!m_var_msb
> && (CEIL (TYPE_PRECISION (lhs_type), limb_prec)
> == CEIL (TYPE_PRECISION (rhs_type), limb_prec))
> - && (!m_upwards_2limb
> - || (m_upwards_2limb * limb_prec
> - < TYPE_PRECISION (lhs_type)
> + && ((!m_upwards_2limb
> + && (TYPE_PRECISION (lhs_type) % limb_prec != 0))
> + || (m_upwards_2limb
> + && (m_upwards_2limb * limb_prec
> + < TYPE_PRECISION (lhs_type))
>{
> rhs1 = handle_operand (rhs1, idx);
> if (tree_fits_uhwi_p (idx))
> --- gcc/testsuite/gcc.dg/torture/bitint-58.c.jj2024-02-12
> 14:58:42.105944347 +0100
> +++ gcc/testsuite/gcc.dg/torture/bitint-58.c2024-02-12 14:44:33.280575269
> +0100
> @@ -0,0 +1,25 @@
> +/* PR tree-optimization/113849 */
> +/* { dg-do run { target bitint } } */
> +/* { dg-options "-std=c23 -pedantic-errors" } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +signed char c;
> +unsigned _BitInt(512) b;
> +
> +__attribute__((noipa)) void
> +foo (unsigned _BitInt(511) a, int *x)
> +{
> + int z = (a << 510) <= b;
> + *x = z + c;
> +}
> +
> +int
> +main ()
> +{
> + int x;
> + foo (2, );
> + if (x != 1)
> +__builtin_abort ();
> + return 0;
> +}
>
>Jakub
>
[Bug fortran/113885] [13/14 Regression] ice in gimplify_expr, at gimplify.cc:18658 with finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |13.3 CC||pault at gcc dot gnu.org Priority|P3 |P4 Known to work||11.4.1, 12.3.1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37336 Keywords||ice-on-valid-code Last reconfirmed||2024-02-12 Summary|ice in gimplify_expr, at|[13/14 Regression] ice in |gimplify.cc:18658 |gimplify_expr, at ||gimplify.cc:18658 with ||finalization Status|UNCONFIRMED |NEW Known to fail||13.2.1, 14.0 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed as a 13/14 regression. Note that adding a component to type t, e.g., so that we have type t integer :: i contains final :: finalize end type t the ICE disappears. Also note that the patch discussed in pr110987 does *not* help here.
[PATCH] testsuite: Add support for scanning assembly with comparitor
There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.
Use case: using different scheduler descriptions and/or cost models will change
assembler output. Testing common functionality across tunes would require a
separate testcase per tune since each assembly output would be different. If we
know a base number of lines should appear across all tunes (i.e. testing return
values: we expect at minimum n stores into register x), we can lower-bound the
test to search for scan-assembler-bound {RE for storing into register x} >= n.
This avoids artificially inflating the scan-assembler-times expected count due
to the assembler choosing to perform extra stores into register x (using it as
a temporary register).
The testcase would be more robust to cpu/tune changes at the cost of not being
as granular towards specific cpu tuning.
gcc/ChangeLog:
* doc/sourcebuild.texi: add scan-assembler-bound
gcc/testsuite/ChangeLog:
* lib/scanasm.exp: add scan-assembler-bound
Signed-off-by: Edwin Lu
---
gcc/doc/sourcebuild.texi | 4 +++
gcc/testsuite/lib/scanasm.exp | 64 +++
2 files changed, 68 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 193be19767f..4a8c672c9fd 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -3396,6 +3396,10 @@ excluding LTO sections.
Passes if @var{regex} is matched exactly @var{num} times in the test's
assembler output, excluding LTO sections.
+@item scan-assembler-bound @var{regex} @var{cmp} @var{num} [@{ target/xfail
@var{selector} @}]
+Passes if @var{regex} is matched @var{cmp} @var{num} times in the test's
+assembler output, excluding LTO sections. @var{cmp} is a comparitor.
+
@item scan-assembler-dem @var{regex} [@{ target/xfail @var{selector} @}]
Passes if @var{regex} matches text in the test's demangled assembler output,
excluding LTO sections.
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 165890eb976..741a5a048b8 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -516,6 +516,70 @@ proc scan-assembler-times { args } {
set_required_options_for scan-assembler-times
+# Call pass if pattern is present within a lower or upper bound,
+# otherwise fail.
+# ex /* { dg-final { scan-assembler-bound {RE} > 3 } }
+proc scan-assembler-bound { args } {
+if { [llength $args] < 3 } {
+ error "scan-assembler-bound: too few arguments"
+return
+}
+if { [llength $args] > 4 } {
+ error "scan-assembler-bound: too many arguments"
+ return
+}
+if { [llength $args] >= 4 } {
+ switch [dg-process-target [lindex $args 3]] {
+ "S" { }
+ "N" { return }
+ "F" { setup_xfail "*-*-*" }
+ "P" { }
+ }
+}
+
+set testcase [testname-for-summary]
+# The name might include a list of options; extract the file name.
+set filename [lindex $testcase 0]
+set pattern [lindex $args 0]
+set cmp [lindex $args 1]
+set bound [lindex $args 2]
+set pp_pattern [make_pattern_printable $pattern]
+
+# This must match the rule in gcc-dg.exp.
+set output_file "[file rootname [file tail $filename]].s"
+
+set files [glob -nocomplain $output_file]
+if { $files == "" } {
+ verbose -log "$testcase: output file does not exist"
+ unresolved "$testcase scan-assembler-bound $pp_pattern $min $max"
+ return
+}
+
+if { [lsearch { < > <= >= } $cmp] == -1 } {
+error "scan-assembler-bound: illegal argument: $cmp"
+return
+}
+if ![string is integer $bound ] {
+error "scan-assembler-bound: illegal argument: $bound"
+return
+}
+
+set fd [open $output_file r]
+set text [read $fd]
+close $fd
+regsub -all
{(^|\n)[[:space:]]*\.section[[:space:]]*"?\.gnu\.lto_(?:[^\n]*\n(?![[:space:]]*\.(section|text|data|bss)))*[^\n]*\n}
$text {\1} text
+
+set result_count [regexp -all -- $pattern $text]
+if [expr $result_count $cmp $bound] {
+ pass "$testcase scan-assembler-bound $pp_pattern $cmp $bound"
+} else {
+ verbose -log "$testcase: $pp_pattern found $result_count times"
+ fail "$testcase scan-assembler-bound $pp_pattern $cmp $bound"
+}
+}
+
+set_required_options_for scan-assembler-bound
+
# Utility for scanning demangled compiler result, invoked via dg-final.
# Call pass if pattern is present, otherwise fail.
proc scan-assembler-dem { args } {
--
2.34.1
Re: [PATCH] attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674]
On 2/12/24 12:30, Jakub Jelinek wrote:
Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
2024-02-12 Jakub Jelinek
PR c++/113674
* attribs.cc (extract_attribute_substring): Remove.
(lookup_scoped_attribute_spec): Don't call it.
* c-c++-common/Wattributes-3.c: New test.
--- gcc/attribs.cc.jj 2024-01-03 11:51:39.392622088 +0100
+++ gcc/attribs.cc 2024-02-12 12:50:00.660458907 +0100
@@ -116,15 +116,6 @@ get_gnu_namespace ()
return gnu_namespace_cache;
}
-/* Return base name of the attribute. Ie '__attr__' is turned into 'attr'.
- To avoid need for copying, we simply return length of the string. */
-
-static void
-extract_attribute_substring (struct substring *str)
-{
- canonicalize_attr_name (str->str, str->length);
-}
-
/* Insert SPECS into its namespace. IGNORED_P is true iff all unknown
attributes in this namespace should be ignored for the purposes of
-Wattributes. The function returns the namespace into which the
@@ -398,7 +389,6 @@ lookup_scoped_attribute_spec (const_tree
attr.str = IDENTIFIER_POINTER (name);
attr.length = IDENTIFIER_LENGTH (name);
- extract_attribute_substring ();
return attrs->attribute_hash->find_with_hash (,
substring_hash (attr.str,
attr.length));
--- gcc/testsuite/c-c++-common/Wattributes-3.c.jj 2024-02-12
13:04:21.964502985 +0100
+++ gcc/testsuite/c-c++-common/Wattributes-3.c 2024-02-12 13:06:32.659688900
+0100
@@ -0,0 +1,13 @@
+/* PR c++/113674 */
+/* { dg-do compile { target { c || c++11 } } } */
+/* { dg-options "" } */
+
+[[noreturn]] int foo (int i) /* { dg-warning "'__noreturn__'
attribute (directive )?ignored" } */
+{
+ return i;
+}
+
+[[maybe_unused]] int bar (int i) /* { dg-warning "'__maybe_unused__'
attribute (directive )?ignored" } */
+{
+ return i;
+}
Jakub
Re: [PATCH] c++: ICE with reinterpret_cast and switch [PR113545]
On 2/10/24 17:42, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK, thanks.
-- >8 --
Jason, this is the patch you proposed for PR113545. It looks very safe
so I'm posting it here so that it's not forgotten.
PR c++/113545
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce
to an INTEGER_CST, consider it non-constant.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-reinterpret3.C: Remove dg-ice.
---
gcc/cp/constexpr.cc | 10 ++
gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C | 4 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 2ebb1470dd5..fa346fe01c9 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -7106,6 +7106,16 @@ cxx_eval_switch_expr (const constexpr_ctx *ctx, tree t,
cond = cxx_eval_constant_expression (ctx, cond, vc_prvalue,
non_constant_p, overflow_p);
VERIFY_CONSTANT (cond);
+ if (TREE_CODE (cond) != INTEGER_CST)
+{
+ /* If the condition doesn't reduce to an INTEGER_CST it isn't a usable
+switch condition even if it's constant enough for other things
+(c++/113545). */
+ gcc_checking_assert (ctx->quiet);
+ *non_constant_p = true;
+ return t;
+}
+
*jump_target = cond;
tree body
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
b/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
index 51feb2e558e..adc0b418df9 100644
--- a/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-reinterpret3.C
@@ -1,7 +1,5 @@
// PR c++/113545
-// { dg-do compile { target c++14 } }
-// Please change the above "dg-do compile" to "dg-do run" when the ICE is
resolved.
-// { dg-ice "PR112545 - constexpr function with switch called for
reinterpret_cast" }
+// { dg-do run { target c++14 } }
char foo;
base-commit: 93e1559bea434a681208e5e7a21513d7da2844d6
prerequisite-patch-id: 9dda211bd29817f18d2d46c3c5a7bbe3708cf9f2
[Bug fortran/113892] New: Missing temporary in assignment for array-valued function referencing host-associated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113892 Bug ID: 113892 Summary: Missing temporary in assignment for array-valued function referencing host-associated array Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- Created attachment 57402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57402=edit Testcase The attached testcase is a slightly rewritten version of the discussion at: https://fortran-lang.discourse.group/t/creating-temporary-array-when-declared-in-a-module/7379 All gfortran versions print: 11 21 31 12 22 32 13 23 33 11 12 13T F F 12 22 23T T F 13 23 33T T T Expected: 11 21 31 12 22 32 13 23 33 11 21 31T T T 12 22 32T T T 13 23 33T T T What happens? Function create_matrix takes the host-associated array "am" and returns the TRANSPOSE(am). When assigning the result directly to "am" we get a wrong result because no temporary is created. Maybe the dependency analysis of assignments needs to take care of the possibility that a non-elemental function might access a host-associated (or USE-associated or COMMON) variable appearing on the lhs.
Re: Optimization of bit field assignemnts
On 12/02/2024 17:47, Hugh Gleaves via Gcc wrote: I’m interested in whether it would be feasible to add an optimization that compacted assignments to multiple bit fields. Today, if I have a 32 bit long struct composed of say, four 8 bit fields and assign constants to them like this: ahb1_ptr->RCC.CFGR.MCO1_PRE = 7; ahb1_ptr->RCC.CFGR.I2SSC = 0; ahb1_ptr->RCC.CFGR.MCO1 = 3; This generates code (on Arm) like this: ahb1_ptr->RCC.CFGR.MCO1_PRE = 7; 0x08000230 ldr.w r1, [r3, #2056] @ 0x808 0x08000234 orr.w r1, r1, #117440512 @ 0x700 0x08000238 str.w r1, [r3, #2056] @ 0x808 ahb1_ptr->RCC.CFGR.I2SSC = 0; 0x0800023c ldr.w r1, [r3, #2056] @ 0x808 0x08000240 bfc r1, #23, #1 0x08000244 str.w r1, [r3, #2056] @ 0x808 ahb1_ptr->RCC.CFGR.MCO1 = 3; 0x08000248 ldr.w r1, [r3, #2056] @ 0x808 0x0800024c orr.w r1, r1, #6291456 @ 0x60 0x08000250 str.w r1, [r3, #2056] @ 0x808 It would be an improvement, if the compiler analyzed these assignments and realized they are all modifications to the same 32 bit datum, generate an appropriate OR and AND bitmask and then apply those to the register and do just a single store at the end. In other words, infer the equivalent of this: RCC->CFGR &= ~0x07E0; RCC->CFGR |=0x0760; This strikes me as very feasible, the compiler knows the offset and bit length of the sub fields so all of the information needed seems to be present. Thoughts… In most such cases, the underlying definition of the structure (or the pointer to the structure) is volatile, because it is a hardware register. The compiler cannot combine the register field settings, because volatile accesses must not be combined - precisely so that programmers can reliably control hardware. It is normal to want to be sure that a particular bitfield is changed, and only after that will the next bitfield be changed, and so on. Sometimes that means the result is slower than it would have to be - but this is much better than giving wrong results when the programmer needs the changes to be handled separately. It is not uncommon for the bytes underlying a hardware register bitfield struct to be available directly as well, letting you do the bit manipulation in a local copy which you then write out in a single operation.
Re: [PATCH] attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674]
On Mon, Feb 12, 2024 at 01:15:55PM -0500, Marek Polacek wrote: > On Mon, Feb 12, 2024 at 06:30:55PM +0100, Jakub Jelinek wrote: > > 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. > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > Looks fine. extract_attribute_substring was added in > https://gcc.gnu.org/pipermail/gcc-patches/2007-July/221563.html > but with no tests. I see that without it gcc.dg/attr-noinline.c > was failing, but that hasn't been the case for many years now. So > I don't know why it would be necessary to keep it. I think it was added far before Martin's changes to canonicalize attributes in r8-2418. At that point attributes in the attributes lists weren't canonicalized, so it was necessary to canonicalize them before or during the lookups. Jakub
Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)
On Mon, Feb 12 2024, Jan Hubicka wrote: >> Hi, >> >> In PR 113476 we have discovered that ipcp_param_lattices is no longer >> a POD and should be destructed. This patch does that, calling >> destructor on each element of the array containing them when the >> corresponding summary of a node is freed. An alternative would be to >> change the XCNEWVEC-and-placement-new to initializations in >> constructors of all things in ipcp_param_lattices and then simply use >> normal operators new and delete. I am not sure, the initialization >> through XCNEWVEC may be a bit more efficient although that is probably >> not a big concern. In the end, I opted for a simpler solution for >> stage 4. >> >> I have verified that valgrind no longer reports lost memory blocks >> allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source >> (dwarf2out.i) attached to Bugzilla. The patch also passes bootstrap and >> LTO bootstrap and testing on x86_64-linux. >> >> OK for master? >> >> Thanks, >> >> Martin >> >> >> gcc/ChangeLog: >> >> 2024-02-09 Martin Jambor >> >> PR tree-optimization/113476 >> * ipa-prop.h (ipa_node_params::~ipa_node_params): Moved... >> * ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here. Added >> destruction of lattices. > > OK. > So you do not use vectors (which would also handle the destruction) > basically to save space needed to keep the > size of the vector since that is known from the parameter count? > Believe it or not, even though I have re-worked the internals of the lattices completely, the array itself is older than my involvement with GCC (or at least with ipa-cp.c ;-). So it being an array and not a vector is historical coincidence, as far as I am concerned :-). But that may be the reason, or because vector macros at that time looked scary, or perhaps the initialization by XCNEWVEC zeroing everything out was considered attractive (I kind of like that but constructors would probably be cleaner), I don't know. Martin
[PATCH] 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.
Running `make check RUNTESTFLAGS="conformance.exp=21_strings/basic_string/*"`
on x86_64-pc-linux-gnu gave unchanged summary results (# of expected passes 570
# of expected failures 4 # of unsupported tests 4).
I don't have write access.
Signed-off-by: Paul Keir
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 43efc99bea9..8a695a494ef 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -909,7 +909,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
__str._M_capacity(__capacity);
}
else
- __str._M_data(__str._M_local_buf);
+ __str._M_data(__str._M_use_local_data());
}
else // Need to do a deep copy
assign(__str);
diff --git
a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
index 0e28a6d4487..ad7548f3236 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/constexpr.cc
@@ -50,3 +50,16 @@ test_erasure()
}
static_assert( test_erasure() );
+
+constexpr bool
+test_move()
+{
+ std::string s1;
+ std::string s2 = "1234567890123456"; // 16 chars: more than _S_local_capacity
+ s1 = std::move(s2);
+ VERIFY( s1 == "1234567890123456" );
+
+ return true;
+}
+
+static_assert( test_move() );
--
Please consider the environment and think before you print.
The University of the West of Scotland is a registered Scottish charity.
Charity number SC002520.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender.
Please note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of the University of the
West of Scotland.
As a public body, the University of the West of Scotland may be required to
make available emails as well as other written forms of information as a result
of a request made under the Freedom of Information (Scotland) Act 2002.
Re: [PATCH] attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674]
On Mon, Feb 12, 2024 at 06:30:55PM +0100, Jakub Jelinek wrote: > Hi! > > 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. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Looks fine. extract_attribute_substring was added in https://gcc.gnu.org/pipermail/gcc-patches/2007-July/221563.html but with no tests. I see that without it gcc.dg/attr-noinline.c was failing, but that hasn't been the case for many years now. So I don't know why it would be necessary to keep it. Marek
[Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9) since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712 --- Comment #20 from Martin Jambor --- I have access to the benchmark and building it with -fprofile-generate it fails for me (with an ICE in add_symbol_to_partition_1) only when I use -fno-use-linker-plugin and either -std=c++11 or -std=c++03. Using -std=c++14 also avoids the issue. In any event, -fno-use-linker-plugin looks necessary.
Re: [PATCH] i386, testsuite: adjust asm patterns
On Sun, Feb 11, 2024 at 11:12 AM Mike Stump wrote: > > On Feb 10, 2024, at 10:07 AM, FX Coudert wrote: > > > > The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is > > partly because symbols are prefixed with underscore, and also because the > > order of operands in the addition is reversed (but I think it’s valid > > still). The code generated is this: > > > > _func: > > LFB0: > >pushq %rbp > > LCFI0: > >movq%rsp, %rbp > > LCFI1: > > # 8 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" > > 1 > >@ _func > > # 0 "" 2 > > # 9 "/Users/fx/gcc-upstream/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c" > > 1 > >@ 4+_var > > # 0 "" 2 > >nop > >popq%rbp > > LCFI2: > >ret > > > > > > > > I’m adjusting the pattern accordingly. > > OK to push? > > Ok. Thanks for commit bbf05e3753c0fd49f1a3bf23897fa96d052ddae9! -- 宋方睿
Re: [PATCH] ipa: call destructors on lattices before freeing them (PR 113476)
> Hi, > > In PR 113476 we have discovered that ipcp_param_lattices is no longer > a POD and should be destructed. This patch does that, calling > destructor on each element of the array containing them when the > corresponding summary of a node is freed. An alternative would be to > change the XCNEWVEC-and-placement-new to initializations in > constructors of all things in ipcp_param_lattices and then simply use > normal operators new and delete. I am not sure, the initialization > through XCNEWVEC may be a bit more efficient although that is probably > not a big concern. In the end, I opted for a simpler solution for > stage 4. > > I have verified that valgrind no longer reports lost memory blocks > allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source > (dwarf2out.i) attached to Bugzilla. The patch also passes bootstrap and > LTO bootstrap and testing on x86_64-linux. > > OK for master? > > Thanks, > > Martin > > > gcc/ChangeLog: > > 2024-02-09 Martin Jambor > > PR tree-optimization/113476 > * ipa-prop.h (ipa_node_params::~ipa_node_params): Moved... > * ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here. Added > destruction of lattices. OK. So you do not use vectors (which would also handle the destruction) basically to save space needed to keep the size of the vector since that is known from the parameter count? Honza
[PATCH] lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849]
Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-12 Jakub Jelinek
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.
* gcc.dg/torture/bitint-58.c: New test.
--- gcc/gimple-lower-bitint.cc.jj 2024-02-10 12:52:10.015925212 +0100
+++ gcc/gimple-lower-bitint.cc 2024-02-12 14:51:58.717472624 +0100
@@ -1267,13 +1267,17 @@ bitint_large_huge::handle_cast (tree lhs
the most significant limb is handled in straight
line code. If m_var_msb (on left shifts) or
if m_upwards_2limb * limb_prec is equal to
-lhs precision that is not the case. */
+lhs precision or if not m_upwards_2limb and lhs_type
+has precision which is multiple of limb_prec that is
+not the case. */
|| (!m_var_msb
&& (CEIL (TYPE_PRECISION (lhs_type), limb_prec)
== CEIL (TYPE_PRECISION (rhs_type), limb_prec))
- && (!m_upwards_2limb
- || (m_upwards_2limb * limb_prec
- < TYPE_PRECISION (lhs_type)
+ && ((!m_upwards_2limb
+ && (TYPE_PRECISION (lhs_type) % limb_prec != 0))
+ || (m_upwards_2limb
+ && (m_upwards_2limb * limb_prec
+ < TYPE_PRECISION (lhs_type))
{
rhs1 = handle_operand (rhs1, idx);
if (tree_fits_uhwi_p (idx))
--- gcc/testsuite/gcc.dg/torture/bitint-58.c.jj 2024-02-12 14:58:42.105944347
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-58.c2024-02-12 14:44:33.280575269
+0100
@@ -0,0 +1,25 @@
+/* PR tree-optimization/113849 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-std=c23 -pedantic-errors" } */
+/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
+/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
+
+signed char c;
+unsigned _BitInt(512) b;
+
+__attribute__((noipa)) void
+foo (unsigned _BitInt(511) a, int *x)
+{
+ int z = (a << 510) <= b;
+ *x = z + c;
+}
+
+int
+main ()
+{
+ int x;
+ foo (2, );
+ if (x != 1)
+__builtin_abort ();
+ return 0;
+}
Jakub
[PATCH] ipa: call destructors on lattices before freeing them (PR 113476)
Hi,
In PR 113476 we have discovered that ipcp_param_lattices is no longer
a POD and should be destructed. This patch does that, calling
destructor on each element of the array containing them when the
corresponding summary of a node is freed. An alternative would be to
change the XCNEWVEC-and-placement-new to initializations in
constructors of all things in ipcp_param_lattices and then simply use
normal operators new and delete. I am not sure, the initialization
through XCNEWVEC may be a bit more efficient although that is probably
not a big concern. In the end, I opted for a simpler solution for
stage 4.
I have verified that valgrind no longer reports lost memory blocks
allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source
(dwarf2out.i) attached to Bugzilla. The patch also passes bootstrap and
LTO bootstrap and testing on x86_64-linux.
OK for master?
Thanks,
Martin
gcc/ChangeLog:
2024-02-09 Martin Jambor
PR tree-optimization/113476
* ipa-prop.h (ipa_node_params::~ipa_node_params): Moved...
* ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here. Added
destruction of lattices.
---
gcc/ipa-cp.cc | 17 +
gcc/ipa-prop.h | 9 -
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index e85477df32d..9864ff052de 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -399,6 +399,23 @@ public:
bool virt_call;
};
+/* Destructor of node function summary, placed here because it mainly must
+ destruct value range lattices not known outside of this source file. */
+
+ipa_node_params::~ipa_node_params ()
+{
+ if (lattices)
+{
+ int count = ipa_get_param_count (this);
+ for (int i = 0; i < count; i++)
+ lattices[i].~ipcp_param_lattices ();
+ free (lattices);
+}
+ vec_free (descriptors);
+ known_csts.release ();
+ known_contexts.release ();
+}
+
/* Allocation pools for values and their sources in ipa-cp. */
object_allocator > ipcp_cst_values_pool
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index 9c78dc9f486..fe401640824 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -670,15 +670,6 @@ ipa_node_params::ipa_node_params ()
{
}
-inline
-ipa_node_params::~ipa_node_params ()
-{
- free (lattices);
- vec_free (descriptors);
- known_csts.release ();
- known_contexts.release ();
-}
-
/* Intermediate information that we get from alias analysis about a particular
parameter in a particular basic_block. When a parameter or the memory it
references is marked modified, we use that information in all dominated
--
2.43.0
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #37 from Andreas Schwab --- No, it uses whatever __rtld_malloc points at, which will be the normal malloc after bootstrap.
[PATCH] attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674]
Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-12 Jakub Jelinek
PR c++/113674
* attribs.cc (extract_attribute_substring): Remove.
(lookup_scoped_attribute_spec): Don't call it.
* c-c++-common/Wattributes-3.c: New test.
--- gcc/attribs.cc.jj 2024-01-03 11:51:39.392622088 +0100
+++ gcc/attribs.cc 2024-02-12 12:50:00.660458907 +0100
@@ -116,15 +116,6 @@ get_gnu_namespace ()
return gnu_namespace_cache;
}
-/* Return base name of the attribute. Ie '__attr__' is turned into 'attr'.
- To avoid need for copying, we simply return length of the string. */
-
-static void
-extract_attribute_substring (struct substring *str)
-{
- canonicalize_attr_name (str->str, str->length);
-}
-
/* Insert SPECS into its namespace. IGNORED_P is true iff all unknown
attributes in this namespace should be ignored for the purposes of
-Wattributes. The function returns the namespace into which the
@@ -398,7 +389,6 @@ lookup_scoped_attribute_spec (const_tree
attr.str = IDENTIFIER_POINTER (name);
attr.length = IDENTIFIER_LENGTH (name);
- extract_attribute_substring ();
return attrs->attribute_hash->find_with_hash (,
substring_hash (attr.str,
attr.length));
--- gcc/testsuite/c-c++-common/Wattributes-3.c.jj 2024-02-12
13:04:21.964502985 +0100
+++ gcc/testsuite/c-c++-common/Wattributes-3.c 2024-02-12 13:06:32.659688900
+0100
@@ -0,0 +1,13 @@
+/* PR c++/113674 */
+/* { dg-do compile { target { c || c++11 } } } */
+/* { dg-options "" } */
+
+[[noreturn]] int foo (int i) /* { dg-warning "'__noreturn__'
attribute (directive )?ignored" } */
+{
+ return i;
+}
+
+[[maybe_unused]] int bar (int i) /* { dg-warning
"'__maybe_unused__' attribute (directive )?ignored" } */
+{
+ return i;
+}
Jakub
[Bug ipa/113890] -fdump-tree-modref ICE with _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113890 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 106783 then. *** This bug has been marked as a duplicate of bug 106783 ***
[Bug ipa/106783] [12/13/14 Regression] ICE in ipa-modref.cc:analyze_function since r12-5247-ga34edf9a3e907de2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106783 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 113890 has been marked as a duplicate of this bug. ***
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #36 from H.J. Lu --- (In reply to Andreas Schwab from comment #35) > ld.so use its internal malloc only during bootstrapping. ___tls_get_addr always uses the internal malloc.
[Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9) since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712 --- Comment #19 from Andrew Pinski --- (In reply to Martin Jambor from comment #18) > (In reply to Filip Kastl from comment #17) > > I've bisected this (using the test from Andrew Pinski) to > > r10-3311-gff6686d2e5f797 > > That's a coincidence, with -fno-ipa-sra the testcase fails even earlier, > IPA-SRA was just hiding it, most probably by localizing some symbol before > the linking stage. > > Bugs that are only reproducible with -fno-use-linker-plugin are unlikely to > get a high priority. But I understand that the original issue does not need > it? I am not 100% sure if the original reported issue had been using the LTO plugin because I could not reproduce it when using the plugin. > > (Also, the issue is supposed to be reproducible ton x86_64-linux, right?) Yes it is supposed to be reproducible on x86_64; I reduced it there.
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #35 from Andreas Schwab --- ld.so use its internal malloc only during bootstrapping.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887
--- Comment #3 from Jens Gustedt ---
(In reply to Jakub Jelinek from comment #1)
> AFAIK glibc doesn't support %w128d etc., it would require full
> int128_t/uint128_t support, likely
> int_least128_t/uint_least128_t/int_fast128_t/uint_fast128_t,
> INT128_WIDTH/UINT128_WIDTH, {,U}INT_{LEAST,FAST}128_WIDTH, INT128_C,
> UINT128_C, ...
>
> I'm not sure one can use wb/uwb literal suffixes because at least in GCC
> _BitInt support is for now x86_64 only (with posted patches for
> ia32/aarch64) and in clang the support is without stable ABI, so perhaps if
> enabled, it would need to be limited to
> __BITINT_MAXWIDTH__ >= 128 targets, because without some __int128 specific
> suffixes or
> __BITINT_MAXWIDTH__ >= 128 one can't support INT128_C or UINT128_C.
yes, sure, but checking that all planets align to provide int128_t is the task
of the headers, which should be provided by the C library, not the compiler.
the compiler provides the feature test macros (for the __int128 types and
_BitInt at least for 128 bit) and with that information the library is able to
provide the remaining information in stdint.h and inttypes.h
The question for the %W flag is just not to confuse the user with wrong
information.
to be clear, all of this works with my current patches for musl without
problem, only the diag given by the compiler is wrong.
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #34 from H.J. Lu --- (In reply to H.J. Lu from comment #33) > (In reply to H.J. Lu from comment #32) > > (In reply to Michael Matz from comment #31) > > > (In reply to H.J. Lu from comment #30) > > > > (In reply to Michael Matz from comment #29) > > > > > It not only can call malloc. As the backtrace of H.J. shows, it quite > > > > > clearly _does_ so :-) > > > > > > > > ld.so can only call the malloc implementation internal to ld.so. > > > > > > (And string functions for initializing that memory) If that's ensured > > > already > > > everywhere: super. Because I agree, that this is the best thing to do > > > here. > > > From my perspective this is pure internal implementation details and hence > > > setting up thread-local areas should not be expected to be interposable by > > > users. > > > (a custom allocator that isn't malloc or doesn't interact with it also > > > would > > > work) > > > > Since ia32 ld.so in glibc is compiled with: > > > > Makefile:rtld-CFLAGS += -mno-sse -mno-mmx -mfpmath=387 > > > > ia32 _dl_tlsdesc_dynamic is OK. > > 387 registers may be an issue. I checked ld.so. It doesn't use 387 registers.
Re: [PATCH] gengtype: Use HOST_SIZE_T_PRINT_UNSIGNED in another spot
> Am 12.02.2024 um 18:14 schrieb Jakub Jelinek :
>
> Hi!
>
> This patch depends on the libiberty/vprintf-support.c change.
>
> Ok for trunk if that one is approved?
Ok
> 2024-02-12 Jakub Jelinek
>
>* gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED
>and cast to fmt_size_t instead of %lu and cast to unsigned long.
>
> --- gcc/gengtype.cc.jj2024-02-10 11:25:10.104472494 +0100
> +++ gcc/gengtype.cc2024-02-12 10:13:49.324612173 +0100
> @@ -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)
>
>Jakub
>
Re: [PATCH] testsuite: Fix up gcc.dg/pr113693.c for ia32
> Am 12.02.2024 um 18:13 schrieb Jakub Jelinek :
>
> Hi!
>
> 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.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (with the ia32 _BitInt
> enablement patch), ok for trunk?
Ok
> 2024-02-12 Jakub Jelinek
>
>* gcc.dg/pr113693.c: Guard _BitInt(837) use with
>__BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of
>dg-message for dbgcnt message.
>
> --- gcc/testsuite/gcc.dg/pr113693.c.jj2024-02-01 20:31:40.592630501 +0100
> +++ gcc/testsuite/gcc.dg/pr113693.c2024-02-12 10:10:30.019384623 +0100
> @@ -1,7 +1,11 @@
> /* { dg-do compile { target bitint } } */
> /* { dg-options "-O2 -fdbg-cnt=vect_loop:1" } */
>
> +#if __BITINT_MAXWIDTH__ >= 837
> _BitInt(837) g, h;
> +#else
> +_BitInt(63) g, h;
> +#endif
>
> void
> fn1(void)
> @@ -10,4 +14,5 @@ fn1(void)
> for (; h; h++)
> ;
> }
> -/* { dg-message "dbgcnt" "" { target *-*-* } 0 } */
> +
> +/* { dg-prune-output "dbgcnt:" } */
>
>Jakub
>
[Bug target/113891] On FreeBSD, a statically linked program which runs a std::thread aborts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891 --- Comment #3 from Andrew Pinski --- I suspect this is due to the use of weak for pthread functions. Most likely you need to force include all of libthr archive file.
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #33 from H.J. Lu --- (In reply to H.J. Lu from comment #32) > (In reply to Michael Matz from comment #31) > > (In reply to H.J. Lu from comment #30) > > > (In reply to Michael Matz from comment #29) > > > > It not only can call malloc. As the backtrace of H.J. shows, it quite > > > > clearly _does_ so :-) > > > > > > ld.so can only call the malloc implementation internal to ld.so. > > > > (And string functions for initializing that memory) If that's ensured > > already > > everywhere: super. Because I agree, that this is the best thing to do here. > > From my perspective this is pure internal implementation details and hence > > setting up thread-local areas should not be expected to be interposable by > > users. > > (a custom allocator that isn't malloc or doesn't interact with it also would > > work) > > Since ia32 ld.so in glibc is compiled with: > > Makefile:rtld-CFLAGS += -mno-sse -mno-mmx -mfpmath=387 > > ia32 _dl_tlsdesc_dynamic is OK. 387 registers may be an issue.
[Bug lto/113712] [11/12/13/14 Regression] lto crash: when building 641.leela_s peek with Example-gcc-linux-x86.cfg (SPEC2017 1.1.9) since r10-3311-gff6686d2e5f797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712 --- Comment #18 from Martin Jambor --- (In reply to Filip Kastl from comment #17) > I've bisected this (using the test from Andrew Pinski) to > r10-3311-gff6686d2e5f797 That's a coincidence, with -fno-ipa-sra the testcase fails even earlier, IPA-SRA was just hiding it, most probably by localizing some symbol before the linking stage. Bugs that are only reproducible with -fno-use-linker-plugin are unlikely to get a high priority. But I understand that the original issue does not need it? (Also, the issue is supposed to be reproducible ton x86_64-linux, right?)
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #32 from H.J. Lu --- (In reply to Michael Matz from comment #31) > (In reply to H.J. Lu from comment #30) > > (In reply to Michael Matz from comment #29) > > > It not only can call malloc. As the backtrace of H.J. shows, it quite > > > clearly _does_ so :-) > > > > ld.so can only call the malloc implementation internal to ld.so. > > (And string functions for initializing that memory) If that's ensured > already > everywhere: super. Because I agree, that this is the best thing to do here. > From my perspective this is pure internal implementation details and hence > setting up thread-local areas should not be expected to be interposable by > users. > (a custom allocator that isn't malloc or doesn't interact with it also would > work) Since ia32 ld.so in glibc is compiled with: Makefile:rtld-CFLAGS += -mno-sse -mno-mmx -mfpmath=387 ia32 _dl_tlsdesc_dynamic is OK.
[Bug target/111677] [12 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 --- Comment #30 from Alex Coplan --- Backport for GCC 12 submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645415.html
[PATCH] gengtype: Use HOST_SIZE_T_PRINT_UNSIGNED in another spot
Hi!
This patch depends on the libiberty/vprintf-support.c change.
Ok for trunk if that one is approved?
2024-02-12 Jakub Jelinek
* gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED
and cast to fmt_size_t instead of %lu and cast to unsigned long.
--- gcc/gengtype.cc.jj 2024-02-10 11:25:10.104472494 +0100
+++ gcc/gengtype.cc 2024-02-12 10:13:49.324612173 +0100
@@ -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)
Jakub
[Bug other/113891] On FreeBSD, a statically linked program which runs a std::thread aborts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891 --- Comment #2 from Steffen --- The program was compiled with g++13 -pthread -static main.cc
[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #31 from Michael Matz --- (In reply to H.J. Lu from comment #30) > (In reply to Michael Matz from comment #29) > > It not only can call malloc. As the backtrace of H.J. shows, it quite > > clearly _does_ so :-) > > ld.so can only call the malloc implementation internal to ld.so. (And string functions for initializing that memory) If that's ensured already everywhere: super. Because I agree, that this is the best thing to do here. >From my perspective this is pure internal implementation details and hence setting up thread-local areas should not be expected to be interposable by users. (a custom allocator that isn't malloc or doesn't interact with it also would work)
[PATCH] testsuite: Fix up gcc.dg/pr113693.c for ia32
Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux (with the ia32 _BitInt
enablement patch), ok for trunk?
2024-02-12 Jakub Jelinek
* gcc.dg/pr113693.c: Guard _BitInt(837) use with
__BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of
dg-message for dbgcnt message.
--- gcc/testsuite/gcc.dg/pr113693.c.jj 2024-02-01 20:31:40.592630501 +0100
+++ gcc/testsuite/gcc.dg/pr113693.c 2024-02-12 10:10:30.019384623 +0100
@@ -1,7 +1,11 @@
/* { dg-do compile { target bitint } } */
/* { dg-options "-O2 -fdbg-cnt=vect_loop:1" } */
+#if __BITINT_MAXWIDTH__ >= 837
_BitInt(837) g, h;
+#else
+_BitInt(63) g, h;
+#endif
void
fn1(void)
@@ -10,4 +14,5 @@ fn1(void)
for (; h; h++)
;
}
-/* { dg-message "dbgcnt" "" { target *-*-* } 0 } */
+
+/* { dg-prune-output "dbgcnt:" } */
Jakub
[Bug other/113891] On FreeBSD, a statically linked program which runs a std::thread aborts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891 --- Comment #1 from Steffen --- Created attachment 57401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57401=edit main.ii
[PATCH][GCC 12] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]
This is a backport of the GCC 13 fix for PR111677 to the GCC 12 branch.
The only part of the patch that isn't a straight cherry-pick is due to
the TX iterator lacking TDmode for GCC 12, so this version adjusts
TX_V16QI accordingly.
Bootstrapped/regtested on aarch64-linux-gnu, the only changes in the
testsuite I saw were in
gcc/testsuite/c-c++-common/hwasan/large-aligned-1.c where the dg-output
"READ of size 4 [...]" check appears to be flaky on the GCC 12 branch
since libhwasan gained the short granule tag feature, I've requested a
backport of the following patch (committed as
r13-100-g3771486daa1e904ceae6f3e135b28e58af33849f) which should fix that
(independent) issue for GCC 12:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645278.html
OK for the GCC 12 branch?
Thanks,
Alex
-- >8 --
The PR shows us ICEing due to an unrecognizable TFmode save emitted by
aarch64_process_components. The problem is that for T{I,F,D}mode we
conservatively require mems to be in range for x-register ldp/stp. That
is because (at least for TImode) it can be allocated to both GPRs and
FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
a q-register load/store.
As Richard pointed out in the PR, aarch64_get_separate_components
already checks that the offsets are suitable for a single load, so we
just need to choose a mode in aarch64_reg_save_mode that gives the full
q-register range. In this patch, we choose V16QImode as an alternative
16-byte "bag-of-bits" mode that doesn't have the artificial range
restrictions imposed on T{I,F,D}mode.
Unlike for GCC 14 we need additional handling in the load/store pair
code as various cases are not expecting to see V16QImode (particularly
the writeback patterns, but also aarch64_gen_load_pair).
gcc/ChangeLog:
PR target/111677
* config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
V16QImode for the full 16-byte FPR saves in the vector PCS case.
(aarch64_gen_storewb_pair): Handle V16QImode.
(aarch64_gen_loadwb_pair): Likewise.
(aarch64_gen_load_pair): Likewise.
* config/aarch64/aarch64.md (loadwb_pair_):
Rename to ...
(loadwb_pair_): ... this, extending to
V16QImode.
(storewb_pair_): Rename to ...
(storewb_pair_): ... this, extending to
V16QImode.
* config/aarch64/iterators.md (TX_V16QI): New.
gcc/testsuite/ChangeLog:
PR target/111677
* gcc.target/aarch64/torture/pr111677.c: New test.
(cherry picked from commit 2bd8264a131ee1215d3bc6181722f9d30f5569c3)
---
gcc/config/aarch64/aarch64.cc | 13 ++-
gcc/config/aarch64/aarch64.md | 35 ++-
gcc/config/aarch64/iterators.md | 3 ++
.../gcc.target/aarch64/torture/pr111677.c | 28 +++
4 files changed, 61 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/aarch64/torture/pr111677.c
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 3bccd96a23d..2bbba323770 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -4135,7 +4135,7 @@ aarch64_reg_save_mode (unsigned int regno)
case ARM_PCS_SIMD:
/* The vector PCS saves the low 128 bits (which is the full
register on non-SVE targets). */
- return TFmode;
+ return V16QImode;
case ARM_PCS_SVE:
/* Use vectors of DImode for registers that need frame
@@ -8602,6 +8602,10 @@ aarch64_gen_storewb_pair (machine_mode mode, rtx base, rtx reg, rtx reg2,
return gen_storewb_pairtf_di (base, base, reg, reg2,
GEN_INT (-adjustment),
GEN_INT (UNITS_PER_VREG - adjustment));
+case E_V16QImode:
+ return gen_storewb_pairv16qi_di (base, base, reg, reg2,
+ GEN_INT (-adjustment),
+ GEN_INT (UNITS_PER_VREG - adjustment));
default:
gcc_unreachable ();
}
@@ -8647,6 +8651,10 @@ aarch64_gen_loadwb_pair (machine_mode mode, rtx base, rtx reg, rtx reg2,
case E_TFmode:
return gen_loadwb_pairtf_di (base, base, reg, reg2, GEN_INT (adjustment),
GEN_INT (UNITS_PER_VREG));
+case E_V16QImode:
+ return gen_loadwb_pairv16qi_di (base, base, reg, reg2,
+ GEN_INT (adjustment),
+ GEN_INT (UNITS_PER_VREG));
default:
gcc_unreachable ();
}
@@ -8730,6 +8738,9 @@ aarch64_gen_load_pair (machine_mode mode, rtx reg1, rtx mem1, rtx reg2,
case E_V4SImode:
return gen_load_pairv4siv4si (reg1, mem1, reg2, mem2);
+case E_V16QImode:
+ return gen_load_pairv16qiv16qi (reg1, mem1, reg2, mem2);
+
default:
gcc_unreachable ();
}
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index fb100bdf6b3..99f185718c9 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1874,17 +1874,18 @@ (define_insn "loadwb_pair_"
[(set_attr "type" "neon_load1_2reg")]
)
-(define_insn "loadwb_pair_"
+(define_insn
[Bug other/113891] New: On FreeBSD, a statically linked program which runs a std::thread aborts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113891 Bug ID: 113891 Summary: On FreeBSD, a statically linked program which runs a std::thread aborts Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: stffn.mobil at freenet dot de Target Milestone: --- Created attachment 57400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57400=edit g++13 -v A simple program which launches a std::thread and is statically linked on FreeBSD aborts. This is not an issue with dynamically linked program. This is also not an issue with LLVM. The gdb backtrace points to the function thread_start in FreeBSD's libthr (thr_create.c). So I thought this would be an issue with the pthread implementation but I sadly can't reproduce this with a C program.
