Re: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args
WTF? ../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node* riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree, vec*)': ../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error: misspelled term 'args' in format; use 'arguments' instead [-Werror=format-diag] 4633 | error_at (loc, "no matching function call to %qE with empty args", fndecl); | ^~~ -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[PATCH] Use HOST_SIZE_T_PRINT_* and HOST_WIDE_INT_T_PRINT_* some more
Hi! I went through suspicios %l in format strings of *printf family functions combined with casts to (long) or (unsigned long) and tried to find out the types of the original expressions that were cast. Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_* macros together with cast to fmt_size_t for those, and then there were quite a few HOST_WIDE_INTs cast to long, used HOST_WIDE_INT_PRINT_* for those without casts. There was one case of a weird unsigned int variable used with %lu and (long) cast too. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-02-10 Jakub Jelinek gcc/ * ipa-icf.cc (sem_item_optimizer::process_cong_reduction, sem_item_optimizer::dump_cong_classes): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. * tree.cc (print_debug_expr_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. (print_value_expr_statistics, print_type_hash_statistics): Likewise. * dwarf2out.cc (output_macinfo_op): Use HOST_WIDE_INT_PRINT_UNSIGNED instead of "%lu" and casts to unsigned long. * gcov-dump.cc (dump_gcov_file): Use %u instead of %lu and casts to unsigned long. * tree-ssa-dom.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * cfgexpand.cc (dump_stack_var_partition): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. * gengtype.cc (adjust_field_rtx_def): Likewise. * tree-into-ssa.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * postreload-gcse.cc (dump_hash_table): Likewise. * ggc-page.cc (alloc_page): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. (ggc_internal_alloc, ggc_free): Likewise. * genpreds.cc (write_lookup_constraint_1): Likewise. (write_insn_constraint_len): Likewise. * tree-dfa.cc (dump_dfa_stats): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * varasm.cc (output_constant_pool_contents): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. * var-tracking.cc (dump_var): Likewise. gcc/c-family/ * c-ada-spec.cc (dump_template_types): Use HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" and casts to unsigned long. gcc/c/ * c-decl.cc (get_parm_array_spec): Use HOST_WIDE_INT_PRINT_UNSIGNED instead of "%lu" and casts to unsigned long or unsigned long long. gcc/cp/ * tree.cc (debug_binfo): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. * pt.cc (print_template_statistics): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. * class.cc (dump_class_hierarchy_1): Use HOST_WIDE_INT_PRINT_UNSIGNED instead of "%lu" and casts to unsigned long. For TYPE_ALIGN, use %u instead of %lu and drop casts to unsigned long. * parser.cc (cp_lexer_peek_nth_token): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. gcc/fortran/ * trans-common.cc (build_common_decl): Use %wu instead of %lu and casts to unsigned long. * resolve.cc (resolve_ordinary_assign): Use %wd instead of %ld and casts to long. * array.cc (gfc_resolve_character_array_constructor): Likewise. * data.cc (create_character_initializer): Likewise. gcc/jit/ * jit-playback.cc (new_bitcast): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. gcc/lto/ * lto-common.cc (print_lto_report_1): Use HOST_SIZE_T_PRINT_DEC and casts to fmt_size_t instead of "%ld" and casts to long. Use %d instead of %ld and casts to long for searches and collisions. --- gcc/ipa-icf.cc.jj 2024-01-12 10:07:58.211851417 +0100 +++ gcc/ipa-icf.cc 2024-02-09 13:02:33.289090629 +0100 @@ -3191,8 +3191,9 @@ sem_item_optimizer::process_cong_reducti worklist_push ((*it)->classes[i]); if (dump_file) -fprintf (dump_file, "Worklist has been filled with: %lu\n", -(unsigned long) worklist.nodes ()); +fprintf (dump_file, "Worklist has been filled with: " + HOST_SIZE_T_PRINT_UNSIGNED "\n", +(fmt_size_t) worklist.nodes ()); if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, "Congruence class reduction\n"); @@ -3239,8 +3240,9 @@ sem_item_optimizer::dump_cong_classes (v } fprintf (dump_file, - "Congruence classes: %lu with total: %u items (in a non-singular " - "class: %u)\n", (unsigned long) m_classes.elements (), + "Congruence clas
[PATCH] Add %[zt][diox] support to pretty-print
Hi!
In the previous patch I haven't touched the gcc diagnostic routines,
using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
want the strings to be translatable. We already have %w[diox] for
HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-02-10 Jakub Jelinek
gcc/
* pretty-print.cc (pp_integer_with_precision): Handle precision 3 for
size_t and precision 4 for ptrdiff_t. Formatting fix.
(pp_format): Document %{t,z}{d,i,u,o,x}. Implement t and z modifiers.
Formatting fixes.
(test_pp_format): Test t and z modifiers.
* gcc.cc (read_specs): Use %td instead of %ld and casts to long.
gcc/c-family/
* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
z modifiers.
gcc/fortran/
* error.cc (error_print): Handle z and t modifiers on d, i and u.
* check.cc (gfc_check_transfer): Use %zd instead of %ld and casts to
long.
* primary.cc (gfc_convert_to_structure_constructor): Use %td instead
of %ld and casts to long.
--- gcc/gcc.cc.jj 2024-02-09 14:54:09.141489744 +0100
+++ gcc/gcc.cc 2024-02-09 22:04:37.655678742 +0100
@@ -2410,8 +2410,7 @@ read_specs (const char *filename, bool m
if (*p1++ != '<' || p[-2] != '>')
fatal_error (input_location,
"specs %%include syntax malformed after "
-"%ld characters",
-(long) (p1 - buffer + 1));
+"%td characters", p1 - buffer + 1);
p[-2] = '\0';
new_filename = find_a_file (&startfile_prefixes, p1, R_OK, true);
@@ -2431,8 +2430,7 @@ read_specs (const char *filename, bool m
if (*p1++ != '<' || p[-2] != '>')
fatal_error (input_location,
"specs %%include syntax malformed after "
-"%ld characters",
-(long) (p1 - buffer + 1));
+"%td characters", p1 - buffer + 1);
p[-2] = '\0';
new_filename = find_a_file (&startfile_prefixes, p1, R_OK, true);
@@ -2458,8 +2456,7 @@ read_specs (const char *filename, bool m
if (! ISALPHA ((unsigned char) *p1))
fatal_error (input_location,
"specs %%rename syntax malformed after "
-"%ld characters",
-(long) (p1 - buffer));
+"%td characters", p1 - buffer);
p2 = p1;
while (*p2 && !ISSPACE ((unsigned char) *p2))
@@ -2468,8 +2465,7 @@ read_specs (const char *filename, bool m
if (*p2 != ' ' && *p2 != '\t')
fatal_error (input_location,
"specs %%rename syntax malformed after "
-"%ld characters",
-(long) (p2 - buffer));
+"%td characters", p2 - buffer);
name_len = p2 - p1;
*p2++ = '\0';
@@ -2479,8 +2475,7 @@ read_specs (const char *filename, bool m
if (! ISALPHA ((unsigned char) *p2))
fatal_error (input_location,
"specs %%rename syntax malformed after "
-"%ld characters",
-(long) (p2 - buffer));
+"%td characters", p2 - buffer);
/* Get new spec name. */
p3 = p2;
@@ -2490,8 +2485,7 @@ read_specs (const char *filename, bool m
if (p3 != p - 1)
fatal_error (input_location,
"specs %%rename syntax malformed after "
-"%ld characters",
-(long) (p3 - buffer));
+"%td characters", p3 - buffer);
*p3 = '\0';
for (sl = specs; sl; sl = sl->next)
@@ -2530,8 +2524,8 @@ read_specs (const char *filename, bool m
}
else
fatal_error (input_location,
-"specs unknown %% command after %ld characters",
-(long) (p1 - buffer));
+"specs unknown %% command after %td characters",
+p1 - buffer);
}
/* Find the colon that should end the suffix. */
@@ -2542,8 +2536,8 @@ read_specs (const char *filename, bool m
/* The colon shouldn't be missing. */
if (*p1 != ':')
fatal_error (input_location,
-"specs file malformed after %ld characters",
-(long) (p1 - buffer));
+"specs file malformed after %td characters",
+p1 - buffer);
/* S
[PATCH] gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754]
Hi!
As the following testcases show, the gimple-low outlining of assume
magic functions handled volatile automatic vars (including
parameters/results) like non-volatile ones except it copied volatile
to the new PARM_DECL, which has the undesirable effect that a load
from the volatile var is passed to IFN_ASSUME and so there is a
side-effect there even when side-effects of the assume attribute
shouldn't be evaluated.
The following patch fixes that by passing address of the volatile
variables/parameters/results instead and doing loads or stores from it
or to it where it was originally accessed in the assume attribute
expression.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
I guess we want to backport it to 13 eventually too.
2024-02-10 Jakub Jelinek
PR middle-end/110754
* gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE
decls create PARM_DECL with pointer to original type, set
TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE,
DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared.
(adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls
wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF.
(lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR
of the var as argument.
* gcc.dg/attr-assume-6.c: New test.
* g++.dg/cpp23/attr-assume12.C: New test.
--- gcc/gimple-low.cc.jj2024-02-01 09:16:51.265388345 +0100
+++ gcc/gimple-low.cc 2024-02-09 15:29:16.003289765 +0100
@@ -374,15 +374,22 @@ assumption_copy_decl (tree decl, copy_bo
gcc_assert (VAR_P (decl)
|| TREE_CODE (decl) == PARM_DECL
|| TREE_CODE (decl) == RESULT_DECL);
+ if (TREE_THIS_VOLATILE (decl))
+type = build_pointer_type (type);
tree copy = build_decl (DECL_SOURCE_LOCATION (decl),
PARM_DECL, DECL_NAME (decl), type);
if (DECL_PT_UID_SET_P (decl))
SET_DECL_PT_UID (copy, DECL_PT_UID (decl));
- TREE_ADDRESSABLE (copy) = TREE_ADDRESSABLE (decl);
- TREE_READONLY (copy) = TREE_READONLY (decl);
- TREE_THIS_VOLATILE (copy) = TREE_THIS_VOLATILE (decl);
- DECL_NOT_GIMPLE_REG_P (copy) = DECL_NOT_GIMPLE_REG_P (decl);
- DECL_BY_REFERENCE (copy) = DECL_BY_REFERENCE (decl);
+ TREE_THIS_VOLATILE (copy) = 0;
+ if (TREE_THIS_VOLATILE (decl))
+TREE_READONLY (copy) = 1;
+ else
+{
+ TREE_ADDRESSABLE (copy) = TREE_ADDRESSABLE (decl);
+ TREE_READONLY (copy) = TREE_READONLY (decl);
+ DECL_NOT_GIMPLE_REG_P (copy) = DECL_NOT_GIMPLE_REG_P (decl);
+ DECL_BY_REFERENCE (copy) = DECL_BY_REFERENCE (decl);
+}
DECL_ARG_TYPE (copy) = type;
((lower_assumption_data *) id)->decls.safe_push (decl);
return copy_decl_for_dup_finish (id, decl, copy);
@@ -466,6 +473,11 @@ adjust_assumption_stmt_op (tree *tp, int
case PARM_DECL:
case RESULT_DECL:
*tp = remap_decl (t, &data->id);
+ if (TREE_THIS_VOLATILE (t) && *tp != t)
+ {
+ *tp = build_simple_mem_ref (*tp);
+ TREE_THIS_NOTRAP (*tp) = 1;
+ }
break;
default:
break;
@@ -600,6 +612,11 @@ lower_assumption (gimple_stmt_iterator *
/* Remaining arguments will be the variables/parameters
mentioned in the condition. */
vargs[i - sz] = lad.decls[i - 1];
+ if (TREE_THIS_VOLATILE (lad.decls[i - 1]))
+ {
+ TREE_ADDRESSABLE (lad.decls[i - 1]) = 1;
+ vargs[i - sz] = build_fold_addr_expr (lad.decls[i - 1]);
+ }
/* If they have gimple types, we might need to regimplify
them to make the IFN_ASSUME call valid. */
if (is_gimple_reg_type (TREE_TYPE (vargs[i - sz]))
--- gcc/testsuite/gcc.dg/attr-assume-6.c.jj 2024-02-09 15:32:49.384325442
+0100
+++ gcc/testsuite/gcc.dg/attr-assume-6.c2024-02-09 15:48:27.612288853
+0100
@@ -0,0 +1,14 @@
+/* PR middle-end/110754 */
+/* { dg-do compile } */
+/* { dg-options "-std=c23 -O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-times "a ={v} x" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-not "={v} a" "optimized" } } */
+/* { dg-final { scan-tree-dump-times "return 0;" 1 "optimized" } } */
+
+int
+foo (int x)
+{
+ volatile int a = x;
+ [[gnu::assume (x == (a & 0))]];
+ return x;
+}
--- gcc/testsuite/g++.dg/cpp23/attr-assume12.C.jj 2024-02-09
15:51:21.100878070 +0100
+++ gcc/testsuite/g++.dg/cpp23/attr-assume12.C 2024-02-09 15:51:51.863450599
+0100
@@ -0,0 +1,14 @@
+// PR middle-end/110754
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2 -fdump-tree-optimized" }
+// { dg-final { scan-tree-dump-times "a ={v} x" 1 "optimized" } }
+// { dg-final { scan-tree-dump-not "={v} a" "optimized" } }
+// { dg-final { scan-tree-dump-times "return 0;" 1 "optimized" } }
+
+int
+foo (int x)
+{
+ volatile int a = x;
+ [[gnu::assume (x == (a & 0))]];
+ return x;
+}
Jakub
Re: [PATCH] Use HOST_SIZE_T_PRINT_* and HOST_WIDE_INT_T_PRINT_* some more
> Am 10.02.2024 um 10:39 schrieb Jakub Jelinek : > > Hi! > > I went through suspicios %l in format strings of *printf family functions > combined with casts to (long) or (unsigned long) and tried to find out the > types of the original expressions that were cast. > Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_* > macros together with cast to fmt_size_t for those, and then there were > quite a few HOST_WIDE_INTs cast to long, used HOST_WIDE_INT_PRINT_* for > those without casts. There was one case of a weird unsigned int variable > used with %lu and (long) cast too. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok Richard > 2024-02-10 Jakub Jelinek > > gcc/ >* ipa-icf.cc (sem_item_optimizer::process_cong_reduction, >sem_item_optimizer::dump_cong_classes): Use HOST_SIZE_T_PRINT_UNSIGNED >and casts to fmt_size_t instead of "%lu" and casts to unsigned long. >* tree.cc (print_debug_expr_statistics): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. >(print_value_expr_statistics, print_type_hash_statistics): Likewise. >* dwarf2out.cc (output_macinfo_op): Use HOST_WIDE_INT_PRINT_UNSIGNED >instead of "%lu" and casts to unsigned long. >* gcov-dump.cc (dump_gcov_file): Use %u instead of %lu and casts to >unsigned long. >* tree-ssa-dom.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. >* cfgexpand.cc (dump_stack_var_partition): Use >HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu" >and casts to unsigned long. >* gengtype.cc (adjust_field_rtx_def): Likewise. >* tree-into-ssa.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. >* postreload-gcse.cc (dump_hash_table): Likewise. >* ggc-page.cc (alloc_page): Use HOST_SIZE_T_PRINT_UNSIGNED >and casts to fmt_size_t instead of "%lu" and casts to unsigned long. >(ggc_internal_alloc, ggc_free): Likewise. >* genpreds.cc (write_lookup_constraint_1): Likewise. >(write_insn_constraint_len): Likewise. >* tree-dfa.cc (dump_dfa_stats): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. >* varasm.cc (output_constant_pool_contents): Use >HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long. >* var-tracking.cc (dump_var): Likewise. > gcc/c-family/ >* c-ada-spec.cc (dump_template_types): Use HOST_SIZE_T_PRINT_UNSIGNED >and casts to fmt_size_t instead of "%lu" and casts to unsigned long. > gcc/c/ >* c-decl.cc (get_parm_array_spec): Use HOST_WIDE_INT_PRINT_UNSIGNED >instead of "%lu" and casts to unsigned long or unsigned long long. > gcc/cp/ >* tree.cc (debug_binfo): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld" >and casts to long. >* pt.cc (print_template_statistics): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. >* class.cc (dump_class_hierarchy_1): Use HOST_WIDE_INT_PRINT_UNSIGNED >instead of "%lu" and casts to unsigned long. For TYPE_ALIGN, use >%u instead of %lu and drop casts to unsigned long. >* parser.cc (cp_lexer_peek_nth_token): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. > gcc/fortran/ >* trans-common.cc (build_common_decl): Use %wu instead of %lu and >casts to unsigned long. >* resolve.cc (resolve_ordinary_assign): Use %wd instead of %ld and >casts to long. >* array.cc (gfc_resolve_character_array_constructor): Likewise. >* data.cc (create_character_initializer): Likewise. > gcc/jit/ >* jit-playback.cc (new_bitcast): Use HOST_WIDE_INT_PRINT_DEC instead >of "%ld" and casts to long. > gcc/lto/ >* lto-common.cc (print_lto_report_1): Use HOST_SIZE_T_PRINT_DEC >and casts to fmt_size_t instead of "%ld" and casts to long. Use >%d instead of %ld and casts to long for searches and collisions. > > --- gcc/ipa-icf.cc.jj2024-01-12 10:07:58.211851417 +0100 > +++ gcc/ipa-icf.cc2024-02-09 13:02:33.289090629 +0100 > @@ -3191,8 +3191,9 @@ sem_item_optimizer::process_cong_reducti >worklist_push ((*it)->classes[i]); > > if (dump_file) > -fprintf (dump_file, "Worklist has been filled with: %lu\n", > - (unsigned long) worklist.nodes ()); > +fprintf (dump_file, "Worklist has been filled with: " > +HOST_SIZE_T_PRINT_UNSIGNED "\n", > + (fmt_size_t) worklist.nodes ()); > > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, "Congruence class reduction\n"); > @@ -3239,8 +3240,9 @@ sem_item_optimizer::dump_cong_classes (v > } > > fprintf (dump_file, > - "Congruence classes: %lu with total: %u items (in a non-singular " > - "class: %u)\n", (unsigned long) m_classes.elements (), > + "Congruence classes: " HOST_SIZE_T_PRINT_UNSIGNED " with to
Re: [PATCH] gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754]
> Am 10.02.2024 um 10:46 schrieb Jakub Jelinek :
>
> Hi!
>
> As the following testcases show, the gimple-low outlining of assume
> magic functions handled volatile automatic vars (including
> parameters/results) like non-volatile ones except it copied volatile
> to the new PARM_DECL, which has the undesirable effect that a load
> from the volatile var is passed to IFN_ASSUME and so there is a
> side-effect there even when side-effects of the assume attribute
> shouldn't be evaluated.
>
> The following patch fixes that by passing address of the volatile
> variables/parameters/results instead and doing loads or stores from it
> or to it where it was originally accessed in the assume attribute
> expression.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> I guess we want to backport it to 13 eventually too.
Ok for trunk and branch after a while.
Richard
> 2024-02-10 Jakub Jelinek
>
>PR middle-end/110754
>* gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE
>decls create PARM_DECL with pointer to original type, set
>TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE,
>DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared.
>(adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls
>wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF.
>(lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR
>of the var as argument.
>
>* gcc.dg/attr-assume-6.c: New test.
>* g++.dg/cpp23/attr-assume12.C: New test.
>
> --- gcc/gimple-low.cc.jj2024-02-01 09:16:51.265388345 +0100
> +++ gcc/gimple-low.cc2024-02-09 15:29:16.003289765 +0100
> @@ -374,15 +374,22 @@ assumption_copy_decl (tree decl, copy_bo
> gcc_assert (VAR_P (decl)
> || TREE_CODE (decl) == PARM_DECL
> || TREE_CODE (decl) == RESULT_DECL);
> + if (TREE_THIS_VOLATILE (decl))
> +type = build_pointer_type (type);
> tree copy = build_decl (DECL_SOURCE_LOCATION (decl),
> PARM_DECL, DECL_NAME (decl), type);
> if (DECL_PT_UID_SET_P (decl))
> SET_DECL_PT_UID (copy, DECL_PT_UID (decl));
> - TREE_ADDRESSABLE (copy) = TREE_ADDRESSABLE (decl);
> - TREE_READONLY (copy) = TREE_READONLY (decl);
> - TREE_THIS_VOLATILE (copy) = TREE_THIS_VOLATILE (decl);
> - DECL_NOT_GIMPLE_REG_P (copy) = DECL_NOT_GIMPLE_REG_P (decl);
> - DECL_BY_REFERENCE (copy) = DECL_BY_REFERENCE (decl);
> + TREE_THIS_VOLATILE (copy) = 0;
> + if (TREE_THIS_VOLATILE (decl))
> +TREE_READONLY (copy) = 1;
> + else
> +{
> + TREE_ADDRESSABLE (copy) = TREE_ADDRESSABLE (decl);
> + TREE_READONLY (copy) = TREE_READONLY (decl);
> + DECL_NOT_GIMPLE_REG_P (copy) = DECL_NOT_GIMPLE_REG_P (decl);
> + DECL_BY_REFERENCE (copy) = DECL_BY_REFERENCE (decl);
> +}
> DECL_ARG_TYPE (copy) = type;
> ((lower_assumption_data *) id)->decls.safe_push (decl);
> return copy_decl_for_dup_finish (id, decl, copy);
> @@ -466,6 +473,11 @@ adjust_assumption_stmt_op (tree *tp, int
> case PARM_DECL:
> case RESULT_DECL:
> *tp = remap_decl (t, &data->id);
> + if (TREE_THIS_VOLATILE (t) && *tp != t)
> +{
> + *tp = build_simple_mem_ref (*tp);
> + TREE_THIS_NOTRAP (*tp) = 1;
> +}
> break;
> default:
> break;
> @@ -600,6 +612,11 @@ lower_assumption (gimple_stmt_iterator *
> /* Remaining arguments will be the variables/parameters
> mentioned in the condition. */
> vargs[i - sz] = lad.decls[i - 1];
> + if (TREE_THIS_VOLATILE (lad.decls[i - 1]))
> +{
> + TREE_ADDRESSABLE (lad.decls[i - 1]) = 1;
> + vargs[i - sz] = build_fold_addr_expr (lad.decls[i - 1]);
> +}
> /* If they have gimple types, we might need to regimplify
> them to make the IFN_ASSUME call valid. */
> if (is_gimple_reg_type (TREE_TYPE (vargs[i - sz]))
> --- gcc/testsuite/gcc.dg/attr-assume-6.c.jj2024-02-09 15:32:49.384325442
> +0100
> +++ gcc/testsuite/gcc.dg/attr-assume-6.c2024-02-09 15:48:27.612288853
> +0100
> @@ -0,0 +1,14 @@
> +/* PR middle-end/110754 */
> +/* { dg-do compile } */
> +/* { dg-options "-std=c23 -O2 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump-times "a ={v} x" 1 "optimized" } } */
> +/* { dg-final { scan-tree-dump-not "={v} a" "optimized" } } */
> +/* { dg-final { scan-tree-dump-times "return 0;" 1 "optimized" } } */
> +
> +int
> +foo (int x)
> +{
> + volatile int a = x;
> + [[gnu::assume (x == (a & 0))]];
> + return x;
> +}
> --- gcc/testsuite/g++.dg/cpp23/attr-assume12.C.jj2024-02-09
> 15:51:21.100878070 +0100
> +++ gcc/testsuite/g++.dg/cpp23/attr-assume12.C2024-02-09
> 15:51:51.863450599 +0100
> @@ -0,0 +1,14 @@
> +// PR middle-end/110754
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-O2 -fdump-tree-optimized" }
> +// { dg-final { scan-tree-dump-times "a ={v} x" 1 "optimized" } }
> +// { dg-final { scan-tree-dump-not "={v} a" "optimized" } }
> +// { dg-final { scan-tree-dump-times "return 0;" 1 "optimi
Re: [PATCH] Add %[zt][diox] support to pretty-print
> Am 10.02.2024 um 10:41 schrieb Jakub Jelinek :
>
> Hi!
>
> In the previous patch I haven't touched the gcc diagnostic routines,
> using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
> want the strings to be translatable. We already have %w[diox] for
> HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok
Thanks,
Richard
> 2024-02-10 Jakub Jelinek
>
> gcc/
>* pretty-print.cc (pp_integer_with_precision): Handle precision 3 for
>size_t and precision 4 for ptrdiff_t. Formatting fix.
>(pp_format): Document %{t,z}{d,i,u,o,x}. Implement t and z modifiers.
>Formatting fixes.
>(test_pp_format): Test t and z modifiers.
>* gcc.cc (read_specs): Use %td instead of %ld and casts to long.
> gcc/c-family/
>* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
>(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
>z modifiers.
> gcc/fortran/
>* error.cc (error_print): Handle z and t modifiers on d, i and u.
>* check.cc (gfc_check_transfer): Use %zd instead of %ld and casts to
>long.
>* primary.cc (gfc_convert_to_structure_constructor): Use %td instead
>of %ld and casts to long.
>
> --- gcc/gcc.cc.jj2024-02-09 14:54:09.141489744 +0100
> +++ gcc/gcc.cc2024-02-09 22:04:37.655678742 +0100
> @@ -2410,8 +2410,7 @@ read_specs (const char *filename, bool m
> if (*p1++ != '<' || p[-2] != '>')
>fatal_error (input_location,
> "specs %%include syntax malformed after "
> - "%ld characters",
> - (long) (p1 - buffer + 1));
> + "%td characters", p1 - buffer + 1);
>
> p[-2] = '\0';
> new_filename = find_a_file (&startfile_prefixes, p1, R_OK, true);
> @@ -2431,8 +2430,7 @@ read_specs (const char *filename, bool m
> if (*p1++ != '<' || p[-2] != '>')
>fatal_error (input_location,
> "specs %%include syntax malformed after "
> - "%ld characters",
> - (long) (p1 - buffer + 1));
> + "%td characters", p1 - buffer + 1);
>
> p[-2] = '\0';
> new_filename = find_a_file (&startfile_prefixes, p1, R_OK, true);
> @@ -2458,8 +2456,7 @@ read_specs (const char *filename, bool m
> if (! ISALPHA ((unsigned char) *p1))
>fatal_error (input_location,
> "specs %%rename syntax malformed after "
> - "%ld characters",
> - (long) (p1 - buffer));
> + "%td characters", p1 - buffer);
>
> p2 = p1;
> while (*p2 && !ISSPACE ((unsigned char) *p2))
> @@ -2468,8 +2465,7 @@ read_specs (const char *filename, bool m
> if (*p2 != ' ' && *p2 != '\t')
>fatal_error (input_location,
> "specs %%rename syntax malformed after "
> - "%ld characters",
> - (long) (p2 - buffer));
> + "%td characters", p2 - buffer);
>
> name_len = p2 - p1;
> *p2++ = '\0';
> @@ -2479,8 +2475,7 @@ read_specs (const char *filename, bool m
> if (! ISALPHA ((unsigned char) *p2))
>fatal_error (input_location,
> "specs %%rename syntax malformed after "
> - "%ld characters",
> - (long) (p2 - buffer));
> + "%td characters", p2 - buffer);
>
> /* Get new spec name. */
> p3 = p2;
> @@ -2490,8 +2485,7 @@ read_specs (const char *filename, bool m
> if (p3 != p - 1)
>fatal_error (input_location,
> "specs %%rename syntax malformed after "
> - "%ld characters",
> - (long) (p3 - buffer));
> + "%td characters", p3 - buffer);
> *p3 = '\0';
>
> for (sl = specs; sl; sl = sl->next)
> @@ -2530,8 +2524,8 @@ read_specs (const char *filename, bool m
>}
> else
>fatal_error (input_location,
> - "specs unknown %% command after %ld characters",
> - (long) (p1 - buffer));
> + "specs unknown %% command after %td characters",
> + p1 - buffer);
>}
>
> /* Find the colon that should end the suffix. */
> @@ -2542,8 +2536,8 @@ read_specs (const char *filename, bool m
> /* The colon shouldn't be missing. */
> if (*p1 != ':')
>fatal_error (input_location,
> - "specs file malformed after %ld characters",
> - (long) (p1 - buffer));
> + "specs file malformed after %td characters",
> + p1 - buffer);
>
> /* Skip back over trailing whitespace. */
> p2 = p1;
> @@ -2556,8 +2550,8 @@ read_specs (const char *filename, bool m
> p = skip_whitespace (p1 + 1);
> if (p[1] == 0)
>fatal_error (input_location,
> - "specs file malformed after %ld characters",
> - (long)
[PATCH] libgcc: Fix BIL_TYPE_SIZE == 32 support in _BitInt <-> dfp support
Hi! I've tried last night to enable _BitInt support for i?86-linux, and a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly didn't do what it was supposed to do. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux (together with patch which enabled the bitint support there), ok for trunk? 2024-02-10 Jakub Jelinek * soft-fp/fixddbitint.c (__bid_fixddbitint): Fix up BIL_TYPE_SIZE == 32 shifts. * soft-fp/fixsdbitint.c (__bid_fixsdbitint): Likewise. * soft-fp/fixtdbitint.c (__bid_fixtdbitint): Likewise. * soft-fp/floatbitintdd.c (__bid_floatbitintdd): Likewise. * soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise. --- libgcc/soft-fp/fixddbitint.c.jj 2023-09-06 17:34:04.976510473 +0200 +++ libgcc/soft-fp/fixddbitint.c2024-02-09 17:05:40.009794653 +0100 @@ -103,7 +103,7 @@ __bid_fixddbitint (UBILtype *r, SItype r #if BIL_TYPE_SIZE == 64 d = limbs[0]; #elif BIL_TYPE_SIZE == 32 - d = (limbs[BITINT_END (0, 1)] << 32) | limbs[BITINT_END (1, 0)]; + d = (UDItype) limbs[BITINT_END (0, 1)] << 32 | limbs[BITINT_END (1, 0)]; #else # error Unsupported BIL_TYPE_SIZE #endif --- libgcc/soft-fp/fixsdbitint.c.jj 2023-09-06 17:34:04.977510460 +0200 +++ libgcc/soft-fp/fixsdbitint.c2024-02-09 17:05:58.104542321 +0100 @@ -104,7 +104,7 @@ __bid_fixsdbitint (UBILtype *r, SItype r #if BIL_TYPE_SIZE == 64 d = limbs[0]; #elif BIL_TYPE_SIZE == 32 - d = (limbs[BITINT_END (0, 1)] << 32) | limbs[BITINT_END (1, 0)]; + d = (UDItype) limbs[BITINT_END (0, 1)] << 32 | limbs[BITINT_END (1, 0)]; #else # error Unsupported BIL_TYPE_SIZE #endif --- libgcc/soft-fp/fixtdbitint.c.jj 2023-09-06 17:34:04.977510460 +0200 +++ libgcc/soft-fp/fixtdbitint.c2024-02-09 17:06:15.781295825 +0100 @@ -126,9 +126,9 @@ __bid_fixtdbitint (UBILtype *r, SItype r mantissalo = limbs[BITINT_END (5, 4)]; rem = limbs[6] | limbs[7]; #elif BIL_TYPE_SIZE == 32 - mantissahi = limbs[BITINT_END (8, 11)] << 32; + mantissahi = (UDItype) limbs[BITINT_END (8, 11)] << 32; mantissahi |= limbs[BITINT_END (9, 10)]; - mantissalo = limbs[BITINT_END (10, 9)] << 32; + mantissalo = (UDItype) limbs[BITINT_END (10, 9)] << 32; mantissalo |= limbs[BITINT_END (11, 8)]; rem = limbs[12] | limbs[13] | limbs[14] | limbs[15]; #endif --- libgcc/soft-fp/floatbitintdd.c.jj 2023-09-06 17:34:04.977510460 +0200 +++ libgcc/soft-fp/floatbitintdd.c 2024-02-09 17:11:47.095675716 +0100 @@ -132,7 +132,7 @@ __bid_floatbitintdd (const UBILtype *i, #if BIL_TYPE_SIZE == 64 m = buf[BITINT_END (1, 0)]; #elif BIL_TYPE_SIZE == 32 - m = ((UDItype) buf[1] << 32) | buf[BITINT_END (2, 0)]; + m = (UDItype) buf[1] << 32 | buf[BITINT_END (2, 0)]; #else # error Unsupported BIL_TYPE_SIZE #endif @@ -212,7 +212,8 @@ __bid_floatbitintdd (const UBILtype *i, mantissa = buf[q_limbs + pow10_limbs * 2 + 1]; #else mantissa - = ((buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 1)] << 32) + = ((UDItype) + buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 1)] << 32 | buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (1, 0)]); #endif } @@ -220,8 +221,7 @@ __bid_floatbitintdd (const UBILtype *i, #if BIL_TYPE_SIZE == 64 mantissa = buf[BITINT_END (1, 0)]; #else - mantissa - = ((buf[1] << 32) | buf[BITINT_END (2, 0)]); + mantissa = (UDItype) buf[1] << 32 | buf[BITINT_END (2, 0)]; #endif } else @@ -232,7 +232,7 @@ __bid_floatbitintdd (const UBILtype *i, if (in == 1) mantissa = iprec < 0 ? (UDItype) (BILtype) msb : (UDItype) msb; else - mantissa = ((msb << 32) | i[BITINT_END (1, 0)]); + mantissa = (UDItype) msb << 32 | i[BITINT_END (1, 0)]; #endif if (iprec < 0) mantissa = -mantissa; --- libgcc/soft-fp/floatbitinttd.c.jj 2023-09-06 17:34:04.978510447 +0200 +++ libgcc/soft-fp/floatbitinttd.c 2024-02-09 17:14:17.485578556 +0100 @@ -196,10 +196,12 @@ __bid_floatbitinttd (const UBILtype *i, mantissalo = buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (1, 0)]; #else mantissahi - = ((buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 3)] << 32) + = ((UDItype) + buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 3)] << 32 | buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (1, 2)]); mantissalo - = ((buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (2, 1)] << 32) + = ((UDItype) + buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (2, 1)] << 32 | buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (3, 0)]); #endif } @@ -209,8 +211,10 @@ __bid_floatbitinttd (const UBILtype *i, mantissahi = buf[BITINT_END (0, 1)]; mantissalo = buf[BITINT_END (1, 0)]; #else - mantissahi = (buf[BITINT_
[PATCH] libgcc: Fix a bug in _BitInt -> dfp conversions
Hi!
The ia32 _BitInt support revealed a bug in floatbitint?d.c.
As can be even guessed from how the code is written in the loop,
the intention was to set inexact to non-zero whenever the remainder
after division wasn't zero, but I've ended up just checking whether
the 2 least significant limbs of the remainder were non-zero.
Now, in the dfp/bitint-4.c test in one case the remainder happens
to have least significant 64 bits zero and then the higher limbs are
non-zero; with 32-bit limbs that means 2 least significant limbs are zero
and so the code acted as if it was exactly divisible.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
(including the _BitInt enablement there), ok for trunk?
2024-02-10 Jakub Jelinek
* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder
limbs into inexact rather than just first two.
* soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise.
* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
--- libgcc/soft-fp/floatbitintdd.c.jj 2024-02-09 17:11:47.095675716 +0100
+++ libgcc/soft-fp/floatbitintdd.c 2024-02-09 18:22:25.786674139 +0100
@@ -114,7 +114,7 @@ __bid_floatbitintdd (const UBILtype *i,
buf + BITINT_END (q_limbs - 1, 0), q_limbs);
inexact = buf[q_limbs + pow10_limbs];
for (j = 1; j < pow10_limbs; ++j)
- inexact |= buf[q_limbs + pow10_limbs + 1];
+ inexact |= buf[q_limbs + pow10_limbs + j];
}
else
{
--- libgcc/soft-fp/floatbitintsd.c.jj 2023-09-06 17:34:04.978510447 +0200
+++ libgcc/soft-fp/floatbitintsd.c 2024-02-09 18:21:50.949158569 +0100
@@ -113,7 +113,7 @@ __bid_floatbitintsd (const UBILtype *i,
buf + BITINT_END (q_limbs - 1, 0), q_limbs);
inexact = buf[q_limbs + pow10_limbs];
for (j = 1; j < pow10_limbs; ++j)
- inexact |= buf[q_limbs + pow10_limbs + 1];
+ inexact |= buf[q_limbs + pow10_limbs + j];
}
else
{
--- libgcc/soft-fp/floatbitinttd.c.jj 2024-02-09 17:14:17.485578556 +0100
+++ libgcc/soft-fp/floatbitinttd.c 2024-02-09 18:21:34.409388566 +0100
@@ -113,7 +113,7 @@ __bid_floatbitinttd (const UBILtype *i,
buf + BITINT_END (q_limbs - 1, 0), q_limbs);
inexact = buf[q_limbs + pow10_limbs];
for (j = 1; j < pow10_limbs; ++j)
- inexact |= buf[q_limbs + pow10_limbs + 1];
+ inexact |= buf[q_limbs + pow10_limbs + j];
}
else
{
Jakub
[PATCH] lower-bitint: Fix up .{ADD,SUB}_OVERFLOW lowering
Hi!
torture/bitint-37.c test FAILed on i686-linux e.g. on
signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
__builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
the IL, 2 in a loop (which handles the first 8 limbs), then one partial
limb (we use 63 bits from that) and finally last_ovf case due to the
mixing of signed vs. unsigned.
But with 32-bit limbs, we use 5 .UADDC calls in the IL, 2 in a loop (which
handles the first 16 limbs), then one full limb above that, one partial
(31 bits) and finally last_ovf case, and for the last_ovf case the code
computed incorrect idx and so partly did the wrong thing, e.g. overwrote
the result from the previous .UADDC.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2024-02-10 Jakub Jelinek
* gimple-lower-bitint.cc (itint_large_huge::lower_addsub_overflow): Fix
computation of idx for i == 4 of bitint_prec_huge.
--- gcc/gimple-lower-bitint.cc.jj 2024-02-09 16:16:55.335552760 +0100
+++ gcc/gimple-lower-bitint.cc 2024-02-09 20:41:50.397455671 +0100
@@ -4031,7 +4031,7 @@ bitint_large_huge::lower_addsub_overflow
if (kind != bitint_prec_huge)
idx = size_int (i);
else if (i >= 2)
- idx = size_int (fin + (i > 2));
+ idx = size_int (fin + i - 2);
if (!last_ovf || i < cnt - 1)
{
if (type0 != TREE_TYPE (arg0))
Jakub
Re: [PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
Il 09/02/24 15:18, Matteo Italia ha scritto:
The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert
the timespec used in gthreads to specify the absolute time for end of
the condition variables timed wait to a milliseconds value relative to
"now" to pass to the Win32 SleepConditionVariableCS function.
Unfortunately, the conversion is incorrect, as, due to a typo, it
returns the relative time _in seconds_, so SleepConditionVariableCS
receives a timeout value 1000 times shorter than it should be, resulting
in a huge amount of spurious wakeups in calls such as
std::condition_variable::wait_for or wait_until.
This can be demonstrated easily by this sample program:
```
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
using sc = std::chrono::system_clock;
auto before = sc::now();
std::unique_lock ml(mx);
if (timed) {
cv.wait_for(ml, std::chrono::seconds(2), [&]{
++wakeups;
return pass;
});
} else {
cv.wait(ml, [&]{
++wakeups;
return pass;
});
}
printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
int((sc::now() - before) / std::chrono::milliseconds(1)));
pass = false;
};
{
// timed wait, let expire
std::thread t(thread_fn, true);
t.join();
}
{
// timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, true);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
{
// non-timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, false);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
return 0;
}
```
On builds that other threading models (e.g. POSIX on Linux, or
winpthreads or MCF on Win32) the output is something like
```
pass: 0; wakeups: 2; elapsed: 2000 ms
pass: 1; wakeups: 2; elapsed: 991 ms
pass: 1; wakeups: 2; elapsed: 996 ms
```
while on the affected builds it's more like
```
pass: 0; wakeups: 1418; elapsed: 2000 ms
pass: 1; wakeups: 479; elapsed: 988 ms
pass: 1; wakeups: 2; elapsed: 992 ms
```
(notice the huge number of wakeups).
This commit fixes the conversion, adjusting the final division by
NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
file and not used in any other place, so the problem here was probably a
typo or some rebase/refactoring mishap).
libgcc/ChangeLog:
* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
fix absolute timespec to relative milliseconds count
conversion (it incorrectly returned seconds instead of
milliseconds); this avoids spurious wakeups in
__gthr_win32_cond_timedwait
---
libgcc/config/i386/gthr-win32-cond.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libgcc/config/i386/gthr-win32-cond.c
b/libgcc/config/i386/gthr-win32-cond.c
index ecb007a54b2..650c448f286 100644
--- a/libgcc/config/i386/gthr-win32-cond.c
+++ b/libgcc/config/i386/gthr-win32-cond.c
@@ -78,7 +78,7 @@ __gthr_win32_abs_to_rel_time (const __gthread_time_t
*abs_time)
if (abs_time_nsec100 < now.nsec100)
return 0;
- return (DWORD) CEIL_DIV (abs_time_nsec100 - now.nsec100, NSEC100_PER_SEC);
+ return (DWORD) CEIL_DIV (abs_time_nsec100 - now.nsec100, NSEC100_PER_MSEC);
}
/* Check the sizes of the local version of the Win32 types. */
Re-reading the commit message I found a few typos, and it was generally
a bit more obscure than I like; reworded it now, hope it's better.From 1592691385f6639b64bd6ec43bdbd8175628fa12 Mon Sep 17 00:00:00 2001
From: Matteo Italia
Date: Fri, 9 Feb 2024 15:04:20 +0100
Subject: [PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait
[PR113850]
To: gcc-patches@gcc.gnu.org
Cc: 10wa...@gmail.com,
ebotca...@adacore.com,
mat...@mitalia.net
Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
relative time in seconds instead of milliseconds. As a consequence,
__gthr_win32_cond_timedwait called SleepConditionVariableCS with a
1000x shorter timeout; this caused ~1000x more spurious wakeups in
CV timed waits such as std::condition_variable::wait_for or wait_until,
resulting generally in much higher CPU usage.
This can be demonstrated by this sample program:
```
#include
#include
#include
#include
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
[RFC PATCH] i386: Enable _BitInt support on ia32
Hi!
Given the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837#c9
comment, the following patch just attempts to implement what I think
is best for ia32.
Compared to https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 ,
like that patch for _BitInt(64) or smaller it uses the smallest containing
{,un}signed {char,short,int,long long} for passing/returning and
layout of variables including in structures for alignment/size, with any
extra bits unspecified.
Unlike the above proposal, for larger _BitInt (i.e. _BitInt(65)+), it uses
passing/returning/layout/alignment of structure containing minimum needed
number of 32-bit limbs, again with the extra bits unspecified.
This is because most operations (except copy or bitwise ops) on _BitInts
aren't really vectorizable and will be under the hood implemented in loops
over 32-bit limbs anyway (using 64-bit limbs under the hood would mean
often using library implementation for the basic operations) and because
ia32 doesn't align even long long/double in structures to 64-bit I think
it is better to just use 32-bit alignment for that. And I don't see
a reason to waste 32-bit bits say for _BitInt(224) or _BitInt(288) on ia32.
So, effectively it is like the x86-64 _BitInt ABI with everything divided by
2, the only exception is that in x86-64 psABI _BitInt(128) is said to be
already a structure of 2 limbs, which happens to be passed mostly the same
as __int128 (except for alignment).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
There are still 2 regressions:
+FAIL: gcc.dg/pr113693.c at line 13 (test for warnings, line )
+FAIL: gcc.dg/torture/bitint-24.c -O0 execution test
+FAIL: gcc.dg/torture/bitint-24.c -O2 execution test
For pr113693.c I think we'll need to do something with the test, either
make it x86_64 specific, add say -msse2 option for ia32, move to
gcc.dg/vect/
And bitint-24.c case seems to be miscompilation of __floatbitintxf
when built with -O2 -m32, it works fine when compiled with -O0 -m32.
Will address that next week.
2024-02-10 Jakub Jelinek
* config/i386/i386.cc (ix86_bitint_type_info): Add support for
!TARGET_64BIT.
--- gcc/config/i386/i386.cc.jj 2024-02-09 11:02:15.193830702 +0100
+++ gcc/config/i386/i386.cc 2024-02-09 16:30:28.568240299 +0100
@@ -25757,13 +25757,11 @@ ix86_get_excess_precision (enum excess_p
bool
ix86_bitint_type_info (int n, struct bitint_info *info)
{
- if (!TARGET_64BIT)
-return false;
if (n <= 8)
info->limb_mode = QImode;
else if (n <= 16)
info->limb_mode = HImode;
- else if (n <= 32)
+ else if (n <= 32 || (!TARGET_64BIT && n > 64))
info->limb_mode = SImode;
else
info->limb_mode = DImode;
Jakub
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
> 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). It would be nice to declare the libraries that are used for both host and target as separate modules in the top level template (since we might want to build them with different configure options; e.g. there’s no real point in bootstrapping the host libstdc++ as a shared lib - pulling in its dependent libs - if we are only going to link the .a). Iain (will check a cross-compiler build with the changes above). > because HOST_LIB_PATH is > appended to the TARGET_EXPORTS (we do not seem to make those depend on the > stage). > > Iain
Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
Hi Florian,
that's been quite a bit. Thank you for putting this together so
comprehensively and thoughtfully, with examples and background!
Note many of my points are suggestions or questions, especially if phrased
as questions or using maybe or similar, so for your consideration.
On Fri, 2 Feb 2024, Florian Weimer wrote:
> htdocs/gcc-14/porting_to.html | 465
> ++
> 1 file changed, 465 insertions(+)
> +
> +Using pointers as integers and vice versa
> (-Werror=int-conversion)
> +It makes sense to address missing int type, implicit
Should this be plural here ("int types") or some adding a
word such as "declaration"? Genuine question.
> +Some of them will be caused by missing types resulting
> +in int, and the default int return type of
> +implicitly declared functions.
...resulting in implicit int... or something like that?
Not sure how to be phrase it.
> + Note that in some cases, it may be more appropriate to pass the
> +address of an integer variable instead of a cast of the variable's
> +value.
I'd omit the comma here since I don't feel the added emphasis is
necessary.
(And maybe simply say "In some cases it may..."?)
> +GCC no longer casts all pointer types to all other pointer types.
Do you mean it no longer does so implicitly, or not at all? That is,
there are now cases where even an explicit cast such as
foo_p = (foo_type*) bar_p
no longer works? Or just
foo_p = bar_p
no longer works for all combinations?
> +To fix the compilation errors resulting from that, you can add the
"To fix compilation errors..."
> +appropriate casts, and maybe consider using code void *
> +in more places (particularly for old programs that predate the
> +introduction of void into the C language).
Here I got confused.
At first I thought I was reading that void * should be used
for cases where void did not exist yet. Now I think I
understand: this is about programs where void * was not used
since it was not part of the language yet - and the encouragement is to
update such old code by using it.
If so, how about making the second case void *, too?
> +Programs that do not carefully track pointer types are likely to
> +contain aliasing violations, so consider building
> +with -fno-strict-aliasing as well.
I suggest omitting "as well" here.
> (Whether the casts
> +are written manually or performed by GCC automatically does not make a
> +difference in terms of strict aliasing violations.)
Here I'd just say "Whether casts are", omitting "the".
> +#include
I *think* we may need to use > here instead of plain '>', though I may
be wrong.
> +To correct this, the callback function should be defined with the
> +correct type
"To address this ... be defined with the correct type"
(To avoid the double "correct"ion.)
> +
> +int
> +compare (const void *a1, const void *b1)
> +{
> + char *const *a = a1;
> + char *const *b = b1;
> + return strcmp (*a, *b);
> +}
> +
Great that you include this example here, that really helps!
Just why "const void *a1" versus "char *const *a", that is, the different
placement of const?
And should it be "const void **a1" and similarly for "b1"??
> +As mentioned initially, adding the cast here would not eliminate any
> +strict aliasing violation in the implementation of
> +the operate function.
Really great you are pointing this out explicitly; thank you!
> +It may be possible to avoid writing manual casts with
> +the -fplan9-extensions options and unnamed
...option... (singular)
> +unrelated to the actual objective of the probe. These failed probes
> +tend to consistently disable program features and their tests, which
> +means that an unexpected probe failure may result in silently dropping
> +features.
Omit "consistently"? I'm not sure what it adds here. And simplify the
second half, something like
These failed probes tend to disable program features (and their tests),
resulting in silently dropping features.
> +In cases where this is a concern, generated config.log,
> +config.h and other source code files can be compared
> +using https://www.gnu.org/software/diffutils/";>diff,
> +to ensure there are no unexpected differences.
I wouldn't link to GNU diffutils here; just refer to the diff
command - or even omit that aspect and leave it at "can be compared".
> +This phenomenon also impacts similar procedures part of CMake, Meson,
> +and various build tools for C extension modules of scripting
> +languages.
"...procedures in CMake..."?
> +
> +Autoconf has supported C99 compilers since at least version 2.69 in
> +its generic, core probes. (Specific functionality probes may have
> +issues addressed in more recent versions.) Versions before 2.69 may
> +have generic probes (for example for standard C support) that rely on
> +C features that were removed in 1999 and thus fail with GCC 14.
"...removed in C99..."? As opposed to compilers removing them in 1999?
> +Sources that cannot be ported t
[PATCH v1] RISC-V: Fix misspelled term args in error_at message
From: Pan Li
When build with "-Werror=format-diag", there will be one misspelled
term args as below. This patch would like fix it by taking the term
arguments instead.
../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree,
vec*)':
../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error:
misspelled term 'args' in format; use 'arguments' instead
[-Werror=format-diag]
4633 | error_at (loc, "no matching function call to %qE with empty
args", fndecl);
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin):
Replace args to arguments for misspelled term.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: Adjust the test cases.
Signed-off-by: Pan Li
---
gcc/config/riscv/riscv-vector-builtins.cc | 3 +-
.../gcc.target/riscv/rvv/base/pr113766-1.c| 126 +-
2 files changed, 65 insertions(+), 64 deletions(-)
diff --git a/gcc/config/riscv/riscv-vector-builtins.cc
b/gcc/config/riscv/riscv-vector-builtins.cc
index efcdc8f1767..c5881a501d1 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -4630,7 +4630,8 @@ resolve_overloaded_builtin (location_t loc, unsigned int
code, tree fndecl,
Here we report error when overloaded function with empty args. */
if (rfun->overloaded_p && arglist->length () == 0)
-error_at (loc, "no matching function call to %qE with empty args", fndecl);
+error_at (loc, "no matching function call to %qE with empty arguments",
+ fndecl);
hashval_t hash = rfun->overloaded_hash (*arglist);
registered_function *rfn
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr113766-1.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr113766-1.c
index fd674a8895c..9e911e31117 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr113766-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr113766-1.c
@@ -6,96 +6,96 @@
void
test ()
{
- __riscv_vand (); /* { dg-error {no matching function call to
'__riscv_vand' with empty args} } */
- __riscv_vand_tu (); /* { dg-error {no matching function call to
'__riscv_vand_tu' with empty args} } */
- __riscv_vand_tumu (); /* { dg-error {no matching function call to
'__riscv_vand_tumu' with empty args} } */
+ __riscv_vand (); /* { dg-error {no matching function call to
'__riscv_vand' with empty arguments} } */
+ __riscv_vand_tu (); /* { dg-error {no matching function call to
'__riscv_vand_tu' with empty arguments} } */
+ __riscv_vand_tumu (); /* { dg-error {no matching function call to
'__riscv_vand_tumu' with empty arguments} } */
- __riscv_vcompress (); /* { dg-error {no matching function call to
'__riscv_vcompress' with empty args} } */
- __riscv_vcompress_tu (); /* { dg-error {no matching function call to
'__riscv_vcompress_tu' with empty args} } */
+ __riscv_vcompress (); /* { dg-error {no matching function call to
'__riscv_vcompress' with empty arguments} } */
+ __riscv_vcompress_tu (); /* { dg-error {no matching function call to
'__riscv_vcompress_tu' with empty arguments} } */
- __riscv_vcpop (); /* { dg-error {no matching function call to
'__riscv_vcpop' with empty args} } */
+ __riscv_vcpop (); /* { dg-error {no matching function call to
'__riscv_vcpop' with empty arguments} } */
- __riscv_vdiv (); /* { dg-error {no matching function call to
'__riscv_vdiv' with empty args} } */
- __riscv_vdiv_tu (); /* { dg-error {no matching function call to
'__riscv_vdiv_tu' with empty args} } */
- __riscv_vdiv_tumu (); /* { dg-error {no matching function call to
'__riscv_vdiv_tumu' with empty args} } */
+ __riscv_vdiv (); /* { dg-error {no matching function call to
'__riscv_vdiv' with empty arguments} } */
+ __riscv_vdiv_tu (); /* { dg-error {no matching function call to
'__riscv_vdiv_tu' with empty arguments} } */
+ __riscv_vdiv_tumu (); /* { dg-error {no matching function call to
'__riscv_vdiv_tumu' with empty arguments} } */
- __riscv_vfabs (); /* { dg-error {no matching function call to
'__riscv_vfabs' with empty args} } */
- __riscv_vfabs_tu (); /* { dg-error {no matching function call to
'__riscv_vfabs_tu' with empty args} } */
- __riscv_vfabs_tumu ();/* { dg-error {no matching function call to
'__riscv_vfabs_tumu' with empty args} } */
+ __riscv_vfabs (); /* { dg-error {no matching function call to
'__riscv_vfabs' with empty arguments} } */
+ __riscv_vfabs_tu (); /* { dg-error {no matching function call to
'__riscv_vfabs_tu' with empty arguments} } */
+ __riscv_vfabs_tumu ();/* { dg-error {no matching function call to
'__riscv_vfabs_tumu' with empty arguments} } */
- __riscv_vfadd ();
Re: [RFC PATCH] i386: Enable _BitInt support on ia32
On Sat, Feb 10, 2024 at 11:19:16AM +0100, Jakub Jelinek wrote: > And bitint-24.c case seems to be miscompilation of __floatbitintxf > when built with -O2 -m32, it works fine when compiled with -O0 -m32. > Will address that next week. Ugh, -O2 -m32 -march=i686 works fine, -O2 -m32 -march=i686 -mtune=generic misbehaves, -O2 -m32 -march=i686 -mtune=generic -fno-ivopts works fine. Will not be fun to debug, the function is large. Jakub
Re: [PATCH] libgcc: Fix BIL_TYPE_SIZE == 32 support in _BitInt <-> dfp support
> Am 10.02.2024 um 10:50 schrieb Jakub Jelinek : > > Hi! > > I've tried last night to enable _BitInt support for i?86-linux, and > a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly > didn't do what it was supposed to do. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux > (together with patch which enabled the bitint support there), ok for trunk? Ok Richard > 2024-02-10 Jakub Jelinek > >* soft-fp/fixddbitint.c (__bid_fixddbitint): Fix up >BIL_TYPE_SIZE == 32 shifts. >* soft-fp/fixsdbitint.c (__bid_fixsdbitint): Likewise. >* soft-fp/fixtdbitint.c (__bid_fixtdbitint): Likewise. >* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Likewise. >* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise. > > --- libgcc/soft-fp/fixddbitint.c.jj2023-09-06 17:34:04.976510473 +0200 > +++ libgcc/soft-fp/fixddbitint.c2024-02-09 17:05:40.009794653 +0100 > @@ -103,7 +103,7 @@ __bid_fixddbitint (UBILtype *r, SItype r > #if BIL_TYPE_SIZE == 64 > d = limbs[0]; > #elif BIL_TYPE_SIZE == 32 > - d = (limbs[BITINT_END (0, 1)] << 32) | limbs[BITINT_END (1, 0)]; > + d = (UDItype) limbs[BITINT_END (0, 1)] << 32 | limbs[BITINT_END (1, > 0)]; > #else > # error Unsupported BIL_TYPE_SIZE > #endif > --- libgcc/soft-fp/fixsdbitint.c.jj2023-09-06 17:34:04.977510460 +0200 > +++ libgcc/soft-fp/fixsdbitint.c2024-02-09 17:05:58.104542321 +0100 > @@ -104,7 +104,7 @@ __bid_fixsdbitint (UBILtype *r, SItype r > #if BIL_TYPE_SIZE == 64 > d = limbs[0]; > #elif BIL_TYPE_SIZE == 32 > - d = (limbs[BITINT_END (0, 1)] << 32) | limbs[BITINT_END (1, 0)]; > + d = (UDItype) limbs[BITINT_END (0, 1)] << 32 | limbs[BITINT_END (1, > 0)]; > #else > # error Unsupported BIL_TYPE_SIZE > #endif > --- libgcc/soft-fp/fixtdbitint.c.jj2023-09-06 17:34:04.977510460 +0200 > +++ libgcc/soft-fp/fixtdbitint.c2024-02-09 17:06:15.781295825 +0100 > @@ -126,9 +126,9 @@ __bid_fixtdbitint (UBILtype *r, SItype r > mantissalo = limbs[BITINT_END (5, 4)]; > rem = limbs[6] | limbs[7]; > #elif BIL_TYPE_SIZE == 32 > - mantissahi = limbs[BITINT_END (8, 11)] << 32; > + mantissahi = (UDItype) limbs[BITINT_END (8, 11)] << 32; > mantissahi |= limbs[BITINT_END (9, 10)]; > - mantissalo = limbs[BITINT_END (10, 9)] << 32; > + mantissalo = (UDItype) limbs[BITINT_END (10, 9)] << 32; > mantissalo |= limbs[BITINT_END (11, 8)]; > rem = limbs[12] | limbs[13] | limbs[14] | limbs[15]; > #endif > --- libgcc/soft-fp/floatbitintdd.c.jj2023-09-06 17:34:04.977510460 +0200 > +++ libgcc/soft-fp/floatbitintdd.c2024-02-09 17:11:47.095675716 +0100 > @@ -132,7 +132,7 @@ __bid_floatbitintdd (const UBILtype *i, > #if BIL_TYPE_SIZE == 64 > m = buf[BITINT_END (1, 0)]; > #elif BIL_TYPE_SIZE == 32 > - m = ((UDItype) buf[1] << 32) | buf[BITINT_END (2, 0)]; > + m = (UDItype) buf[1] << 32 | buf[BITINT_END (2, 0)]; > #else > # error Unsupported BIL_TYPE_SIZE > #endif > @@ -212,7 +212,8 @@ __bid_floatbitintdd (const UBILtype *i, > mantissa = buf[q_limbs + pow10_limbs * 2 + 1]; > #else > mantissa > -= ((buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 1)] << 32) > += ((UDItype) > + buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 1)] << 32 > | buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (1, 0)]); > #endif >} > @@ -220,8 +221,7 @@ __bid_floatbitintdd (const UBILtype *i, > #if BIL_TYPE_SIZE == 64 >mantissa = buf[BITINT_END (1, 0)]; > #else > -mantissa > - = ((buf[1] << 32) | buf[BITINT_END (2, 0)]); > +mantissa = (UDItype) buf[1] << 32 | buf[BITINT_END (2, 0)]; > #endif > } > else > @@ -232,7 +232,7 @@ __bid_floatbitintdd (const UBILtype *i, > if (in == 1) >mantissa = iprec < 0 ? (UDItype) (BILtype) msb : (UDItype) msb; > else > -mantissa = ((msb << 32) | i[BITINT_END (1, 0)]); > +mantissa = (UDItype) msb << 32 | i[BITINT_END (1, 0)]; > #endif > if (iprec < 0) >mantissa = -mantissa; > --- libgcc/soft-fp/floatbitinttd.c.jj2023-09-06 17:34:04.978510447 +0200 > +++ libgcc/soft-fp/floatbitinttd.c2024-02-09 17:14:17.485578556 +0100 > @@ -196,10 +196,12 @@ __bid_floatbitinttd (const UBILtype *i, > mantissalo = buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (1, 0)]; > #else > mantissahi > -= ((buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 3)] << 32) > += ((UDItype) > + buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (0, 3)] << 32 > | buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (1, 2)]); > mantissalo > -= ((buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (2, 1)] << 32) > += ((UDItype) > + buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (2, 1)] << 32 > | buf[q_limbs + pow10_limbs * 2 + 1 + BITINT_END (3, 0)]); > #endif >} > @@ -209,8 +211,10 @@ __bid_floatbitinttd (const UBILtype *i, > mantissahi = buf[BITINT
Re: [PATCH] libgcc: Fix a bug in _BitInt -> dfp conversions
> Am 10.02.2024 um 10:56 schrieb Jakub Jelinek :
>
> Hi!
>
> The ia32 _BitInt support revealed a bug in floatbitint?d.c.
> As can be even guessed from how the code is written in the loop,
> the intention was to set inexact to non-zero whenever the remainder
> after division wasn't zero, but I've ended up just checking whether
> the 2 least significant limbs of the remainder were non-zero.
> Now, in the dfp/bitint-4.c test in one case the remainder happens
> to have least significant 64 bits zero and then the higher limbs are
> non-zero; with 32-bit limbs that means 2 least significant limbs are zero
> and so the code acted as if it was exactly divisible.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux
> (including the _BitInt enablement there), ok for trunk?
Ok
Richard
> 2024-02-10 Jakub Jelinek
>
>* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder
>limbs into inexact rather than just first two.
>* soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise.
>* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
>
> --- libgcc/soft-fp/floatbitintdd.c.jj2024-02-09 17:11:47.095675716 +0100
> +++ libgcc/soft-fp/floatbitintdd.c2024-02-09 18:22:25.786674139 +0100
> @@ -114,7 +114,7 @@ __bid_floatbitintdd (const UBILtype *i,
> buf + BITINT_END (q_limbs - 1, 0), q_limbs);
> inexact = buf[q_limbs + pow10_limbs];
> for (j = 1; j < pow10_limbs; ++j)
> -inexact |= buf[q_limbs + pow10_limbs + 1];
> +inexact |= buf[q_limbs + pow10_limbs + j];
>}
> else
>{
> --- libgcc/soft-fp/floatbitintsd.c.jj2023-09-06 17:34:04.978510447 +0200
> +++ libgcc/soft-fp/floatbitintsd.c2024-02-09 18:21:50.949158569 +0100
> @@ -113,7 +113,7 @@ __bid_floatbitintsd (const UBILtype *i,
> buf + BITINT_END (q_limbs - 1, 0), q_limbs);
> inexact = buf[q_limbs + pow10_limbs];
> for (j = 1; j < pow10_limbs; ++j)
> -inexact |= buf[q_limbs + pow10_limbs + 1];
> +inexact |= buf[q_limbs + pow10_limbs + j];
>}
> else
>{
> --- libgcc/soft-fp/floatbitinttd.c.jj2024-02-09 17:14:17.485578556 +0100
> +++ libgcc/soft-fp/floatbitinttd.c2024-02-09 18:21:34.409388566 +0100
> @@ -113,7 +113,7 @@ __bid_floatbitinttd (const UBILtype *i,
> buf + BITINT_END (q_limbs - 1, 0), q_limbs);
> inexact = buf[q_limbs + pow10_limbs];
> for (j = 1; j < pow10_limbs; ++j)
> -inexact |= buf[q_limbs + pow10_limbs + 1];
> +inexact |= buf[q_limbs + pow10_limbs + j];
>}
> else
>{
>
>Jakub
>
Re: [PATCH] lower-bitint: Fix up .{ADD,SUB}_OVERFLOW lowering
> Am 10.02.2024 um 11:03 schrieb Jakub Jelinek :
>
> Hi!
>
> torture/bitint-37.c test FAILed on i686-linux e.g. on
> signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
> __builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
> the IL, 2 in a loop (which handles the first 8 limbs), then one partial
> limb (we use 63 bits from that) and finally last_ovf case due to the
> mixing of signed vs. unsigned.
> But with 32-bit limbs, we use 5 .UADDC calls in the IL, 2 in a loop (which
> handles the first 16 limbs), then one full limb above that, one partial
> (31 bits) and finally last_ovf case, and for the last_ovf case the code
> computed incorrect idx and so partly did the wrong thing, e.g. overwrote
> the result from the previous .UADDC.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
Ok
Richard
> 2024-02-10 Jakub Jelinek
>
>* gimple-lower-bitint.cc (itint_large_huge::lower_addsub_overflow): Fix
>computation of idx for i == 4 of bitint_prec_huge.
>
> --- gcc/gimple-lower-bitint.cc.jj2024-02-09 16:16:55.335552760 +0100
> +++ gcc/gimple-lower-bitint.cc2024-02-09 20:41:50.397455671 +0100
> @@ -4031,7 +4031,7 @@ bitint_large_huge::lower_addsub_overflow
> if (kind != bitint_prec_huge)
>idx = size_int (i);
> else if (i >= 2)
> -idx = size_int (fin + (i > 2));
> +idx = size_int (fin + i - 2);
> if (!last_ovf || i < cnt - 1)
>{
> if (type0 != TREE_TYPE (arg0))
>
>Jakub
>
[PATCH] Darwin, testsuite: -bind_at_load is deprecated
With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning: ld: warning: -bind_at_load is deprecated on macOS The patches ignores the warning when present. OK to push? FX 0001-Darwin-testsuite-bind_at_load-is-deprecated.patch Description: Binary data
Re: [PATCH] Darwin, testsuite: -bind_at_load is deprecated
Hi FX, > On 10 Feb 2024, at 11:58, FX Coudert wrote: > > With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning: > ld: warning: -bind_at_load is deprecated on macOS > > The patches ignores the warning when present. > OK to push? Yes, thanks. Iain I guess for GCC-15 we might need to see which options should now be stripped for new(er) darwin. > > FX > > > <0001-Darwin-testsuite-bind_at_load-is-deprecated.patch>
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
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? Jason
Re: [PATCH 1/2] c++/modules: reduce lazy loading recursion
On 2/9/24 16:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk
-- >8 --
It turns out that with modules we can call mangle_decl recursively,
which is a problem because the global mangling state isn't recursion
aware. The recursion happens from write_closure_type_name, which calls
lambda_function, which performs name lookup, which can trigger lazy
loading, which can call maybe_clone_body for a newly loaded cdtor, which
can inspect DECL_ASSEMBLER_NAME, which enters mangling. This was observed
when using fmtlib as a module with trunk and it leads to a bogus
"mangling conflicts with a previous mangle error" followed by an ICE
from cdtor_comdat_group due to a mangling mismatch.
This patch fixes this by sidestepping lazy loading when performing the
op() lookup in lambda_function, so that we don't accidentally end up
entering mangling recursively. This should be safe since the lazy load
should still get triggered by some other name lookup.
In passing it was noticed that lazy loading can get quite recursive
ultimately due to the name lookups from check_local_shadow, which may
perform lazy loading, which cause us to instantiate/clone things, which
end up calling check_local_shadow. This patch fixes this by
implementating an optimization suggested by Jason:
I think we shouldn't bother with check_local_shadow in a clone or
instantiation, only when actually parsing.
This reduces the maximum depth of lazy loading recursion for a simple
modular Hello World from ~115 to ~12.
gcc/cp/ChangeLog:
* lambda.cc (lambda_function): Call get_class_binding_direct
instead of lookup_member to sidestep lazy loading.
* name-lookup.cc (check_local_shadow): Punt if we're in a
function context that's definitely not actual parsing.
---
gcc/cp/lambda.cc | 4 +---
gcc/cp/name-lookup.cc | 17 +
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
index 1d37e5a52b9..4b1f9391fee 100644
--- a/gcc/cp/lambda.cc
+++ b/gcc/cp/lambda.cc
@@ -175,9 +175,7 @@ lambda_function (tree lambda)
if (CLASSTYPE_TEMPLATE_INSTANTIATION (type)
&& !COMPLETE_OR_OPEN_TYPE_P (type))
return NULL_TREE;
- lambda = lookup_member (type, call_op_identifier,
- /*protect=*/0, /*want_type=*/false,
- tf_warning_or_error);
+ lambda = get_class_binding_direct (type, call_op_identifier);
if (lambda)
lambda = STRIP_TEMPLATE (get_first_fn (lambda));
return lambda;
diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
index e58f3b5cb4d..ca5ba87bc76 100644
--- a/gcc/cp/name-lookup.cc
+++ b/gcc/cp/name-lookup.cc
@@ -3275,6 +3275,23 @@ check_local_shadow (tree decl)
if (TREE_CODE (decl) == PARM_DECL && !DECL_CONTEXT (decl))
return NULL_TREE;
+ if (DECL_FUNCTION_SCOPE_P (decl))
+{
+ tree ctx = DECL_CONTEXT (decl);
+ if (DECL_CLONED_FUNCTION_P (ctx)
+ || DECL_TEMPLATE_INSTANTIATED (ctx)
+ || (DECL_LANG_SPECIFIC (ctx)
+ && DECL_DEFAULTED_FN (ctx))
+ || (LAMBDA_FUNCTION_P (ctx)
+ && LAMBDA_EXPR_REGEN_INFO (CLASSTYPE_LAMBDA_EXPR
+(DECL_CONTEXT (ctx)
Maybe these tests should be factored out in case other places want to
check the same condition? OK either way.
+ /* It suffices to check shadowing only when actually parsing.
+ So punt for clones, instantiations, defaulted functions and
+ regenerated lambdas. This optimization helps lazy loading
+ cascades with modules. */
+ return NULL_TREE;
+}
+
tree old = NULL_TREE;
cp_binding_level *old_scope = NULL;
if (cxx_binding *binding = outer_binding (DECL_NAME (decl), NULL, true))
Re: [PATCH 2/2] c++/modules: ICE with modular fmtlib
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. Jason
Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]
> 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. Iain > Jason
[PATCH] [X86_64]: Enable support for next generation AMD Zen5 CPU with znver5 scheduler Model
[Public] Hi all, PFA, the patch that enables support for the next generation AMD Zen5 CPU via -march=znver5 with basic znver5 scheduler Model. We may update the scheduler model going forward. Good for trunk? Thanks and Regards Karthiban Resending the patch, as unable to inline the patch here. reason : awaits moderator approval Message body is too big: 601858 bytes with a limit of 400 KB 0001-Add-AMD-znver5-processor-enablement-with-scheduler-m.patch Description: 0001-Add-AMD-znver5-processor-enablement-with-scheduler-m.patch
ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html
May I please ping this one? Thanks!
On Sat, Jan 13, 2024 at 5:12 PM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704
>
> The below patch fixes the issue noted in the PR that extended characters
> cannot appear in the identifier passed to a #pragma push_macro or #pragma
> pop_macro. Bootstrap + regtest all languages on x86-64 Linux. Is it OK for
> GCC 13 please?
>
> I know we just entered stage 4, however I feel this is kinda like an old
> regression, given that the issue was not apparent until support for UCNs and
> UTF-8 in identifiers got added. FWIW, it would be nice if it makes it into
> GCC 13, because AFAIK all other UTF-8-related bugs are fixed in this
> release. (The other major one was for extended characters in a user-defined
> literal, that was fixed by r14-2629).
>
> Speaking of just entering stage 4. I do have 4 really short patches sent
> over the past several months that never got any response. Is there any
> chance someone may have a few minutes to look at them please? They are
> really just like 1-3 line fixes for PRs.
>
> libcpp (pinged once recently):
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640386.html
>
> diagnostics (pinged for 3rd time last week):
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html
> -- >8 --
>
> The implementation of #pragma push_macro and #pragma pop_macro has to date
> made use of an ad-hoc function, _cpp_lex_identifier(), which lexes an
> identifier out of a string. When support was added for extended characters
> in identifiers ($, UCNs, or UTF-8), that support was added only for the
> "normal" way of lexing identifiers out of a cpp_buffer (_cpp_lex_direct) and
> not for the ad-hoc way. Consequently, extended identifiers are not usable
> with these pragmas.
>
> The logic for lexing identifiers has become more complicated than it was
> when _cpp_lex_identifier() was written -- it now handles things like \N{}
> escapes in C++, for instance -- and it no longer seems practical to maintain
> a redundant code path for lexing identifiers. Address the issue by changing
> the implementation of #pragma {push,pop}_macro to lex identifiers in the
> expected way, i.e. by pushing a cpp_buffer and lexing the identifier from
> there.
>
> The existing implementation has some quirks because of the ad-hoc parsing
> logic. For example:
>
> #pragma push_macro("X ")
> ...
> #pragma pop_macro("X")
>
> will not restore macro X (note the extra space in the first string). However:
>
> #pragma push_macro("X ")
> ...
> #pragma pop_macro("X ")
>
> actually does sucessfully restore "X". This is because the key for looking
> up the saved macro on the push stack is the original string passed, so the
> string passed to pop_macro needs to match it exactly. It is not that easy to
> reproduce this logic in the world of extended characters, given that for
> example it should be valid to pass a UCN to push_macro, and the
> corresponding UTF-8 to pop_macro. Given that this aspect of the existing
> behavior seems unintentional and has no tests (and does not match other
> implementations), I opted to make the new logic more straightforward. The
> string passed needs to lex to one token, which must be a valid identifier,
> or else no action is taken and no error is generated. Any diagnostics
> encountered during lexing (e.g., due to a UTF-8 character not permitted to
> appear in an identifier) are also suppressed.
>
> It could be nice (for GCC 15) to also add a warning if a pop_macro does not
> match a previous push_macro.
>
> libcpp/ChangeLog:
>
> PR preprocessor/109704
> * include/cpplib.h (class cpp_auto_suppress_diagnostics): New class.
> * errors.cc
> (cpp_auto_suppress_diagnostics::cpp_auto_suppress_diagnostics): New
> function.
> (cpp_auto_suppress_diagnostics::~cpp_auto_suppress_diagnostics): New
> function.
> * charset.cc (noop_diagnostic_cb): Remove.
> (cpp_interpret_string_ranges): Refactor diagnostic suppression logic
> into new class cpp_auto_suppress_diagnostics.
> (count_source_chars): Likewise.
> * directives.cc (cpp_pop_definition): Add cpp_hashnode argument.
> (lex_identifier_from_string): New static helper function.
> (push_pop_macro_common): Refactor common logic from
> do_pragma_push_macro and do_pragma_pop_macro; use
> lex_identifier_from_string instead of _cpp_lex_identifier.
> (do_pragma_push_macro): Reimplement using push_pop_macro_common.
> (do_pragma_pop_macro): Likewise.
> * internal.h (_cpp_lex_identifier): Remove.
> * lex.cc (lex_identifier_intern): Remove.
> (_cpp_lex_identifier): Remove.
>
> gcc/testsuite/ChangeLog:
>
> PR preprocessor/109704
> * c-c++-common/cpp/pragm
[PATCH] Darwin, testsuite: -multiply_defined is obsolete
With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is obsolete The patches ignores the warning when present. OK to push? FX 0001-Darwin-testsuite-multiply_defined-is-obsolete.patch Description: Binary data
Re: [PATCH] Darwin, testsuite: -multiply_defined is obsolete
> On 10 Feb 2024, at 14:54, FX Coudert wrote: > > With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is > obsolete > > The patches ignores the warning when present. > OK to push? yes, thanks. Iain … although part of me is curious about whether we still have any supported OS version for which the “-multiply_defined,suppress” is needed, we should try to put that evaluation on the GCC-15 TODO. > > FX > > <0001-Darwin-testsuite-multiply_defined-is-obsolete.patch>
[PATCH] testsuite: Update test case to comply with GCC14 changes
I have confirmed that this updated pr97969.c file still hangs with
gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.
Ok for trunk?
--
The test case for PR97969 needs updates in order to comply with recent
changes in GCC14. Without these changes, failures like this can be seen
on arm-none-eabi:
.../pr97969.c:6:9: error: type defaults to 'int' in declaration of 'a'
[-Wimplicit-int]
.../pr97969.c:34:1: error: return type defaults to 'int' [-Wimplicit-int]
.../pr97969.c:40:3: error: implicit declaration of function 'ae'
[-Wimplicit-function-declaration]
.../pr97969.c:42:3: error: implicit declaration of function 'af'
[-Wimplicit-function-declaration]
.../pr97969.c:43:7: error: implicit declaration of function 'ag'
[-Wimplicit-function-declaration]
.../pr97969.c:46:10: error: assignment to 'char *' from 'int' makes pointer
from integer without a cast [-Wint-conversion]
.../pr97969.c:48:10: error: assignment to 'char *' from 'int' makes pointer
from integer without a cast [-Wint-conversion]
.../pr97969.c:50:8: error: implicit declaration of function 'setjmp'
[-Wimplicit-function-declaration]
.../pr97969.c:51:5: error: implicit declaration of function 'ah'
[-Wimplicit-function-declaration]
.../pr97969.c:52:5: error: implicit declaration of function 'ai'
[-Wimplicit-function-declaration]
.../pr97969.c:54:5: error: implicit declaration of function 'aj'
[-Wimplicit-function-declaration]
Patch has been verified on Linux.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr97969.c: Update to comply with GCC14 changes.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/pr97969.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/pr97969.c
b/gcc/testsuite/gcc.target/arm/pr97969.c
index b8c3a23676a..af69e47ad9f 100644
--- a/gcc/testsuite/gcc.target/arm/pr97969.c
+++ b/gcc/testsuite/gcc.target/arm/pr97969.c
@@ -3,17 +3,17 @@
/* { dg-options "-std=c99 -fno-omit-frame-pointer -w -Os" } */
/* { dg-add-options arm_arch_v6m } */
-typedef a[23];
+typedef int a[23];
enum { b };
typedef struct {
int c;
char *e;
- char f
+ char f;
} d;
typedef enum { g = 1 } h;
typedef struct {
h i;
- int j
+ int j;
} k;
typedef struct {
a l;
@@ -29,9 +29,18 @@ typedef struct {
d t;
d *u;
short v;
- int w
+ int w;
} aa;
-c(char x, int y, char z, int ab) {
+
+void ae(short*, int, int);
+void af(aa*, int, char, int);
+int ag(int);
+void ah(aa);
+void ai(int);
+void aj(aa);
+int setjmp();
+
+int c(char x, int y, char z, int ab) {
aa ac;
ac.r.i = 0;
d ad;
@@ -43,9 +52,9 @@ c(char x, int y, char z, int ab) {
if (ag(0))
return 0;
if (x)
-ac.s = z + ab;
+ac.s = (char*)(z + ab);
else
-ac.s = x + y;
+ac.s = (char*)(x + y);
ac.o |= g;
if (!setjmp()) {
ah(ac);
--
2.25.1
[PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].
I have so far tested this on i686-darwin17 and on x86_64-linux (with 32b
multilib )with the following permutations:
C (dg.exp=*nest*), Ada :
\{-m64,-m32\}\{,-ftrampoline-impl=heap\}\{,-shared-libgcc\}
Fortran \{-m64,-m32\}\{,-ftrampoline-impl=heap\}
The only fails [gnat] are expected (scanning for GNU-stack when the impl. is
heap).
Testing to follow on i686-darwin9 (32b kernel) and x86_64-darwin17 with the
corresponding multilibs.
I do not have ready access to an i686-linux host.
How does this look to resolve the PR?
Iain
--- 8< ---
The initial heap trampoline implementation was targeting 64b
platforms. As the PR demonstrates this creates an issue where it
is expected that the same symbols are exported for 32 and 64b.
Rather than conditionalize the exports and code-gen on x86_64,
this patch provides a basic implementation of the IA32 trampoline.
This also avoids potential user confusion, when a 32b target has
64b multilibs, and vice versa; which is the case for Darwin.
PR target/113855
gcc/ChangeLog:
* config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
available to all sub-targets.
* config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
* config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete.
libgcc/ChangeLog:
* config.host: Add trampoline support to x?86-linux.
* config/i386/heap-trampoline.c (trampoline_insns): Provide
a variant for IA32.
(union ix86_trampoline): Likewise.
(__gcc_nested_func_ptr_created): Implement a basic trampoline
for IA32.
---
gcc/config/i386/darwin.h | 3 ++-
gcc/config/i386/darwin32-biarch.h| 3 ---
gcc/config/i386/darwin64-biarch.h| 3 ---
libgcc/config.host | 1 +
libgcc/config/i386/heap-trampoline.c | 40 +---
5 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/gcc/config/i386/darwin.h b/gcc/config/i386/darwin.h
index 8e64b4e9b5f..bf9c45d70bb 100644
--- a/gcc/config/i386/darwin.h
+++ b/gcc/config/i386/darwin.h
@@ -119,9 +119,10 @@ along with GCC; see the file COPYING3. If not see
/* We default to x86_64 for single-arch builds, bi-arch overrides. */
#define DARWIN_ARCH_SPEC "x86_64"
#define DARWIN_SUBARCH_SPEC DARWIN_ARCH_SPEC
+#endif
+
#undef DARWIN_HEAP_T_LIB
#define DARWIN_HEAP_T_LIB " -lheapt_w "
-#endif
#undef SUBTARGET_EXTRA_SPECS
#define SUBTARGET_EXTRA_SPECS \
diff --git a/gcc/config/i386/darwin32-biarch.h
b/gcc/config/i386/darwin32-biarch.h
index 2180f5a5352..051ad12b425 100644
--- a/gcc/config/i386/darwin32-biarch.h
+++ b/gcc/config/i386/darwin32-biarch.h
@@ -27,9 +27,6 @@ along with GCC; see the file COPYING3. If not see
#undef DARWIN_SUBARCH_SPEC
#define DARWIN_SUBARCH_SPEC DARWIN_ARCH_SPEC
-#undef DARWIN_HEAP_T_LIB
-#define DARWIN_HEAP_T_LIB " %{m64:-lheapt_w}"
-
#undef SUBTARGET_EXTRA_SPECS
#define SUBTARGET_EXTRA_SPECS \
DARWIN_EXTRA_SPECS\
diff --git a/gcc/config/i386/darwin64-biarch.h
b/gcc/config/i386/darwin64-biarch.h
index 620800749a8..85436791a6c 100644
--- a/gcc/config/i386/darwin64-biarch.h
+++ b/gcc/config/i386/darwin64-biarch.h
@@ -28,9 +28,6 @@ along with GCC; see the file COPYING3. If not see
#undef DARWIN_SUBARCH_SPEC
#define DARWIN_SUBARCH_SPEC DARWIN_ARCH_SPEC
-#undef DARWIN_HEAP_T_LIB
-#define DARWIN_HEAP_T_LIB "%{!m32:-lheapt_w}"
-
#undef SUBTARGET_EXTRA_SPECS
#define SUBTARGET_EXTRA_SPECS \
DARWIN_EXTRA_SPECS\
diff --git a/libgcc/config.host b/libgcc/config.host
index 3e7d00f67aa..59a42d3a01f 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -774,6 +774,7 @@ i[34567]86-*-linux*)
tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff
t-dfprules"
tm_file="${tm_file} i386/elf-lib.h"
md_unwind_header=i386/linux-unwind.h
+ tmake_file="${tmake_file} i386/t-heap-trampoline"
;;
i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-kopensolaris*-gnu)
extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o
crtfastmath.o"
diff --git a/libgcc/config/i386/heap-trampoline.c
b/libgcc/config/i386/heap-trampoline.c
index 657b344c10c..1df0aa06108 100644
--- a/libgcc/config/i386/heap-trampoline.c
+++ b/libgcc/config/i386/heap-trampoline.c
@@ -29,12 +29,13 @@ void *allocate_trampoline_page (void);
void __gcc_nested_func_ptr_created (void *chain, void *func, void *dst);
void __gcc_nested_func_ptr_deleted (void);
+#if __x86_64__
static const uint8_t trampoline_insns[] = {
- /* movabs $,%r11 */
+ /* movabs $,%r11 */
0x49, 0xbb,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- /* movabs $,%r10 */
+ /* movabs $,%r10 */
0x49, 0xba,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
@@ -54,6 +55,33 @@ union ix86_trampoline {
} fields;
};
+#elif __i386__
+
+static cons
[PATCHv2 0/2] Changes to libiberty buildargv
I realise that these patches are not going to get merged until GCC is back in stage 1, but thought I'd post my latest set of changes for the libiberty buildargv function. Patch #1 is unchanged from V1. Patch #2 is new in V2. Thanks, Andrew --- Andrew Burgess (2): libiberty/buildargv: POSIX behaviour for backslash handling libiberty/buildargv: handle input consisting of only white space libiberty/argv.c | 104 libiberty/testsuite/test-expandargv.c | 170 ++ 2 files changed, 200 insertions(+), 74 deletions(-) base-commit: cff174fabd6c980c09aee95db1d9d5c22421761f -- 2.25.4
[PATCHv2 2/2] libiberty/buildargv: handle input consisting of only white space
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and noticed
some unexpected behaviour to the libiberty function buildargv, when
the input is a string consisting only of white space.
What I observe is that if the input to buildargv is a string
containing only white space, then buildargv will return an argv list
containing a single empty argument, e.g.:
char **argv = buildargv (" ");
assert (*argv[0] == '\0');
assert (argv[1] == NULL);
We get the same output from buildargv if the input is a single space,
or multiple spaces. Other white space characters give the same
results.
This doesn't seem right to me, and in fact, there appears to be a work
around for this issue in expandargv where we have this code:
/* If the file is empty or contains only whitespace, buildargv would
return a single empty argument. In this context we want no arguments,
instead. */
if (only_whitespace (buffer))
{
file_argv = (char **) xmalloc (sizeof (char *));
file_argv[0] = NULL;
}
else
/* Parse the string. */
file_argv = buildargv (buffer);
I think that the correct behaviour in this situation is to return an
empty argv array, e.g.:
char **argv = buildargv (" ");
assert (argv[0] == NULL);
And it turns out that this is a trivial change to buildargv. The diff
does look big, but this is because I've re-indented a block. Check
with 'git diff -b' to see the minimal changes. I've also removed the
work around from expandargv.
When testing this sort of thing I normally write the tests first, and
then fix the code. In this case test-expandargv.c has sort-of been
used as a mechanism for testing the buildargv function (expandargv
does call buildargv most of the time), however, for this particular
issue the work around in expandargv (mentioned above) masked the
buildargv bug.
I did consider adding a new test-buildargv.c file, however, this would
have basically been a copy & paste of test-expandargv.c (with some
minor changes to call buildargv). This would be fine now, but feels
like we would eventually end up with one file not being updated as
much as the other, and so test coverage would suffer.
Instead, I have added some explicit buildargv testing to the
test-expandargv.c file, this reuses the test input that is already
defined for expandargv.
Of course, once I removed the work around from expandargv then we now
do always call buildargv from expandargv, and so the bug I'm fixing
would impact both expandargv and buildargv, so maybe the new testing
is redundant? I tend to think more testing is always better, so I've
left it in for now.
---
libiberty/argv.c | 108 ++--
libiberty/testsuite/test-expandargv.c | 136 ++
2 files changed, 166 insertions(+), 78 deletions(-)
diff --git a/libiberty/argv.c b/libiberty/argv.c
index d9d32e59e72..675336273f3 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -212,71 +212,74 @@ char **buildargv (const char *input)
argv[argc] = NULL;
}
/* Begin scanning arg */
- arg = copybuf;
- while (*input != EOS)
+ if (*input != EOS)
{
- if (ISSPACE (*input) && !squote && !dquote && !bsquote)
+ arg = copybuf;
+ while (*input != EOS)
{
- break;
- }
- else
- {
- if (bsquote)
- {
- bsquote = 0;
- if (*input != '\n')
- *arg++ = *input;
- }
- else if (*input == '\\'
- && !squote
- && (!dquote
- || strchr ("$`\"\\\n", *(input + 1)) != NULL))
+ if (ISSPACE (*input) && !squote && !dquote && !bsquote)
{
- bsquote = 1;
- }
- else if (squote)
- {
- if (*input == '\'')
- {
- squote = 0;
- }
- else
- {
- *arg++ = *input;
- }
+ break;
}
- else if (dquote)
+ else
{
- if (*input == '"')
+ if (bsquote)
{
- dquote = 0;
+ bsquote = 0;
+ if (*input != '\n')
+ *arg++ = *input;
}
- else
+ else if (*input == '\\'
+
[PATCHv2 1/2] libiberty/buildargv: POSIX behaviour for backslash handling
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour to the libiberty
function buildargv, and how it handles backslash escapes.
For reference, I've been mostly reading:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
The issues that I would like to fix are:
1. Backslashes within single quotes should not be treated as an
escape, thus: '\a' should split to \a, retaining the backslash.
2. Backslashes within double quotes should only act as an escape if
they are immediately before one of the characters $ (dollar),
` (backtick), " (double quote), ` (backslash), or \n (newline). In
all other cases a backslash should not be treated as an escape
character. Thus: "\a" should split to \a, but "\$" should split to
$.
3. A backslash-newline sequence should be treated as a line
continuation, both the backslash and the newline should be removed.
I've updated libiberty and also added some tests. All the existing
libiberty tests continue to pass, but I'm not sure if there is more
testing that should be done, buildargv is used within lto-wraper.cc,
so maybe there's some testing folk can suggest that I run?
---
libiberty/argv.c | 8 +--
libiberty/testsuite/test-expandargv.c | 34 +++
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/libiberty/argv.c b/libiberty/argv.c
index 45f16854603..d9d32e59e72 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -224,9 +224,13 @@ char **buildargv (const char *input)
if (bsquote)
{
bsquote = 0;
- *arg++ = *input;
+ if (*input != '\n')
+ *arg++ = *input;
}
- else if (*input == '\\')
+ else if (*input == '\\'
+ && !squote
+ && (!dquote
+ || strchr ("$`\"\\\n", *(input + 1)) != NULL))
{
bsquote = 1;
}
diff --git a/libiberty/testsuite/test-expandargv.c
b/libiberty/testsuite/test-expandargv.c
index 1e9cb0a0d5a..ea1aeb0eda2 100644
--- a/libiberty/testsuite/test-expandargv.c
+++ b/libiberty/testsuite/test-expandargv.c
@@ -142,6 +142,40 @@ const char *test_data[] = {
"b",
0,
+ /* Test 7 - No backslash removal within single quotes. */
+ "'a\\$VAR' '\\\"'",/* Test 7 data */
+ ARGV0,
+ "@test-expandargv-7.lst",
+ 0,
+ ARGV0,
+ "a\\$VAR",
+ "\\\"",
+ 0,
+
+ /* Test 8 - Remove backslash / newline pairs. */
+ "\"ab\\\ncd\" ef\\\ngh",/* Test 8 data */
+ ARGV0,
+ "@test-expandargv-8.lst",
+ 0,
+ ARGV0,
+ "abcd",
+ "efgh",
+ 0,
+
+ /* Test 9 - Backslash within double quotes. */
+ "\"\\$VAR\" \"\\`\" \"\\\"\" \"\" \"\\n\" \"\\t\"",/* Test 9 data */
+ ARGV0,
+ "@test-expandargv-9.lst",
+ 0,
+ ARGV0,
+ "$VAR",
+ "`",
+ "\"",
+ "\\",
+ "\\n",
+ "\\t",
+ 0,
+
0 /* Test done marker, don't remove. */
};
--
2.25.4
Re: [PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].
On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote: > PR target/113855 > > gcc/ChangeLog: > > * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be > available to all sub-targets. > * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete. > * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete. > > libgcc/ChangeLog: > > * config.host: Add trampoline support to x?86-linux. > * config/i386/heap-trampoline.c (trampoline_insns): Provide > a variant for IA32. > (union ix86_trampoline): Likewise. > (__gcc_nested_func_ptr_created): Implement a basic trampoline > for IA32. LGTM. I bet it probably doesn't work properly for -mx32 (which defines __x86_64__), CCing H.J. on that, but that is a preexisting issue (and I don't have any experience with it; I guess one would either need to add 4 bytes of padding after the func_ptr so that those bits remain zeros as sizeof (void *) is 4, but presumably it would be better to just use movl (but into %r10) and maybe the jmpl instead of movabsq. Jakub
[pushed] Darwin, testsuite: skip some -mcmodel=large tests
Three new tests using -mcmodel=large, which darwin does not support. Skipping them. Pushed as obvious. FX 0001-Darwin-testsuite-skip-some-mcmodel-large-tests.patch Description: Binary data
Re: [PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].
> On 10 Feb 2024, at 17:46, Jakub Jelinek wrote: > > On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote: >> PR target/113855 >> >> gcc/ChangeLog: >> >> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be >> available to all sub-targets. >> * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete. >> * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete. >> >> libgcc/ChangeLog: >> >> * config.host: Add trampoline support to x?86-linux. >> * config/i386/heap-trampoline.c (trampoline_insns): Provide >> a variant for IA32. >> (union ix86_trampoline): Likewise. >> (__gcc_nested_func_ptr_created): Implement a basic trampoline >> for IA32. > > LGTM. > > I bet it probably doesn't work properly for -mx32 (which defines > __x86_64__), CCing H.J. on that, but that is a preexisting issue > (and I don't have any experience with it; I guess one would either > need to add 4 bytes of padding after the func_ptr so that those > bits remain zeros as sizeof (void *) is 4, but presumably it would be > better to just use movl (but into %r10) and maybe the jmpl instead > of movabsq. It seems that ix86_trampoline_init flips codegen on TARGET_64BIT so perhaps if we make it __x86_64__ && __LP64__? I had also considered maybe forcing the alignment of the trampoline allocations to a cache line (or maybe at least half a cache line). These considerations are also something to add to the improvements we can make to generalize the handling. For now, assuming remaining testing does not throw up any new issues, I’ll apply this to make progress on the PR. thanks Iain > > Jakub >
Re: [PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].
On Sat, Feb 10, 2024 at 9:46 AM Jakub Jelinek wrote: > > On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote: > > PR target/113855 > > > > gcc/ChangeLog: > > > > * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be > > available to all sub-targets. > > * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete. > > * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete. > > > > libgcc/ChangeLog: > > > > * config.host: Add trampoline support to x?86-linux. > > * config/i386/heap-trampoline.c (trampoline_insns): Provide > > a variant for IA32. > > (union ix86_trampoline): Likewise. > > (__gcc_nested_func_ptr_created): Implement a basic trampoline > > for IA32. > > LGTM. > > I bet it probably doesn't work properly for -mx32 (which defines > __x86_64__), CCing H.J. on that, but that is a preexisting issue > (and I don't have any experience with it; I guess one would either > need to add 4 bytes of padding after the func_ptr so that those > bits remain zeros as sizeof (void *) is 4, but presumably it would be > better to just use movl (but into %r10) and maybe the jmpl instead > of movabsq. > > Jakub > Are there any testcases to exercise this code on Linux? -- H.J.
[PATCH] i386, testsuite: adjust asm patterns
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? FX 0001-i386-testsuite-adjust-asm-patterns.patch Description: Binary data
Re: [PATCH 2/2] c++/modules: ICE with modular fmtlib
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:
-- >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_s
[PATCH] Add Myself to Write After Approval and DCO List
Hello, I have added myself to write after approval. Thanks, Alexander Westbrooks >From 564b307970d3be7a02e827420f0fad87bd335d9b Mon Sep 17 00:00:00 2001 From: Alexander Westbrooks Date: Sat, 10 Feb 2024 12:20:00 -0600 Subject: [PATCH] Add Myself to Write After Approval and DCO List ChangeLog: * MAINTAINERS: Add myself to write after approval and DCO. Signed-off-by: Alexander Westbrooks --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3720344308e..617133447f0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -714,6 +714,7 @@ Stephen M. Webb John Wehle Florian Weimer Zack Weinberg +Alexander Westbrooks Mark Wielaard Edmar Wienskoski Ollie Wild @@ -778,4 +779,5 @@ Edward Smith-Rowland Petter Tomner Martin Uecker Jonathan Wakely +Alexander Westbrooks Chung-Ju Wu -- 2.25.1
[PATCH] c++: SFINAE-unfriendly error on throwing pointer [PR112436]
Probably stage1 material but it should be safe...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >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 +861,7 @@ is_admissible_throw_operand_or_catch_parameter (tree t,
bool is_throw)
restrictions on type matching mentioned in 15.3, the operand
Re: [April 2022 PING] cpp: new built-in __EXP_COUNTER__
On 2023-08-28 10:09, Kaz Kylheku wrote: > On 2022-06-13 16:13, Kaz Kylheku wrote: >> Pinging this item: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593473.html >> >> Thanks. Again.
Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers
I managed to try this patch on aarch64-linux-gnu:
This is the test run without your patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807637.html
And this is the "result" with your patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807645.html
For me, as for you, it works for x86_64-linux-gnu:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807609.html
I hope this helps.
Kind regards,
Toon Moene.
On 2/9/24 11:26, Richard Biener wrote:
The following allows a base term to be derived from an existing
MEM_EXPR, notably the points-to set of a MEM_REF base. For the
testcase in the PR this helps RTL DSE elide stores to a stack
temporary. This covers pointers to NONLOCAL which can be mapped
to arg_base_value, helping to disambiguate against other special
bases (ADDRESS) as well as PARM_DECL accesses.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
This is an attempt to recover some of the losses from dumbing down
find_base_{term,value}. I did give my ideas how to properly do
this during stage1 a start, I will post a short incomplete RFC series
later today.
OK for trunk?
I've included all languages in testing and also tested with -m32 but
details of RTL alias analysis might escape me ...
Thanks,
Richard.
PR rtl-optimization/113597
* alias.cc (find_base_term): Add argument for the whole mem
and derive a base term from its MEM_EXPR.
(true_dependence_1): Pass down the MEMs to find_base_term.
(write_dependence_p): Likewise.
(may_alias_p): Likewise.
---
gcc/alias.cc | 43 ---
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/gcc/alias.cc b/gcc/alias.cc
index 6fad4b29d31..e33c56b0e80 100644
--- a/gcc/alias.cc
+++ b/gcc/alias.cc
@@ -40,6 +40,9 @@ along with GCC; see the file COPYING3. If not see
#include "rtl-iter.h"
#include "cgraph.h"
#include "ipa-utils.h"
+#include "stringpool.h"
+#include "value-range.h"
+#include "tree-ssanames.h"
/* The aliasing API provided here solves related but different problems:
@@ -190,6 +193,10 @@ static struct {
arguments, since we do not know at this level whether accesses
based on different arguments can alias. The ADDRESS has id 0.
+ This is solely useful to disambiguate against other ADDRESS
+ bases as we know incoming pointers cannot point to local
+ stack, frame or argument space.
+
2. stack_pointer_rtx, frame_pointer_rtx, hard_frame_pointer_rtx
(if distinct from frame_pointer_rtx) and arg_pointer_rtx.
Each of these rtxes has a separate ADDRESS associated with it,
@@ -2113,12 +2120,34 @@ find_base_term (rtx x, vec
static rtx
-find_base_term (rtx x)
+find_base_term (rtx x, const_rtx mem = NULL_RTX)
{
auto_vec, 32> visited_vals;
rtx res = find_base_term (x, visited_vals);
for (unsigned i = 0; i < visited_vals.length (); ++i)
visited_vals[i].first->locs = visited_vals[i].second;
+ if (!res && mem && MEM_EXPR (mem))
+{
+ tree base = get_base_address (MEM_EXPR (mem));
+ if (TREE_CODE (base) == PARM_DECL
+ && DECL_RTL_SET_P (base))
+ /* We need to look at how we expanded a PARM_DECL. It might be in
+ the argument space (UNIQUE_BASE_VALUE_ARGP) or it might
+ be spilled (UNIQUE_BASE_VALUE_FP/UNIQUE_BASE_VALUE_HFP). */
+ res = find_base_term (DECL_RTL (base));
+ else if (TREE_CODE (base) == MEM_REF
+ && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
+ && SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0)))
+ {
+ auto pt = &SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0))->pt;
+ if (pt->nonlocal
+ && !pt->anything
+ && !pt->escaped
+ && !pt->ipa_escaped
+ && bitmap_empty_p (pt->vars))
+ res = arg_base_value;
+ }
+}
return res;
}
@@ -3035,13 +3064,13 @@ true_dependence_1 (const_rtx mem, machine_mode mem_mode, rtx mem_addr,
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
return true;
- base = find_base_term (x_addr);
+ base = find_base_term (x_addr, x);
if (base && (GET_CODE (base) == LABEL_REF
|| (GET_CODE (base) == SYMBOL_REF
&& CONSTANT_POOL_ADDRESS_P (base
return false;
- rtx mem_base = find_base_term (true_mem_addr);
+ rtx mem_base = find_base_term (true_mem_addr, mem);
if (! base_alias_check (x_addr, base, true_mem_addr, mem_base,
GET_MODE (x), mem_mode))
return false;
@@ -3142,7 +3171,7 @@ write_dependence_p (const_rtx mem,
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
return true;
- base = find_base_term (true_mem_addr);
+ base = find_base_term (true_mem_addr, mem);
if (! writep
&& base
&& (GET_CODE (base) == LABEL_REF
@@ -3150,7 +3179,7 @@ write_dependence_p (const_rtx mem,
&& CONSTANT_POOL_ADDRESS
Re: [PATCH] Revert "Pass GUILE down to subdirectories"
> "Andrew" == Andrew Burgess writes: Andrew> Tom Tromey writes: >> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. >> >> This patch caused problems for some users when building gdb, because >> it would cause 'guild' to be invoked with the wrong versin of guile. >> On the whole it seems simpler to just back this out. >> >> * Makefile.in: Rebuild. >> * Makefile.tpl (BASE_EXPORTS): Remove GUILE. >> (GUILE): Remove. >> * Makefile.def (flags_to_pass): Remove GUILE. Andrew> Is it going to be possible to merge this with GCC in stage 4? Would be Andrew> super useful if we could as this is still causing problems. We can always check it in to gdb now and then to gcc at some later date. If that sounds ok to you, I'll go ahead & do it. thanks, Tom
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
Hi! On Tue, 6 Feb 2024 at 06:37, Alexandre Oliva wrote: > > Hello, Christophe, > > Thanks for the patch. > > On Feb 5, 2024, Christophe Lyon wrote: > > > In order to save build time, our CI overrides BUILD_INFO="", which > > works when invoking 'make all' but not for 'make install' in case some > > info files need an update. > > Hmm, I don't think this would be desirable. We ship updated info files > in release tarballs, and it would be desirable to install them even if > makeinfo is not available in the build environment. > > > I noticed this when testing a patch posted on the gcc-patches list, > > leading to an error at 'make install' time after updating tm.texi (the > > build reported 'new text' in tm.texi and stopped). This is because > > 'install' depends on 'install-info', which depends on > > $(DESTDIR)$(infodir)/gccint.info (among others). > > Ideally, we'd detect and report info files that are out-of-date WRT > their ultimate sources, especially to catch tm.texi.in changes, but > doing so only at install time is clearly suboptimal. > > I mean, if we don't have the tools to build info files, it's fine if we > skip their building, and even refrain from installing info files that > are missing or outdated, but we should install prebuilt ones if they're > available, and we should probably *not* refrain from trying to satisfy > the dependencies for info files at build time, even if it turns out that > we can't build the info files themselves. > > This suggests to me that, rather than setting BUILD_INFO to the empty > string, we should set it to e.g. no-info, so that $(MAKEINFO) will not > be run because x$(BUILD_INFO) != xinfo, but so that we still get the > dependencies resolved, e.g. by making no-info depend on info. Or maybe > make it info-check-deps, and insert that between info and its current > deps. WDYT? I've just spent quite a bit of time looking at your suggestion, and well... I hadn't considered the case of makeinfo missing/too old, in our use case makeinfo is present and recent enough but we want to save a few minutes of build time during the CI loop. As I mentioned, we (tried to) do this by doing BUILD_INFO="" when invoking 'make', and it took me ages to realize it is not working as expected, because GCC's top-level Makefile does not propagate BUILD_INFO recursively, and this conflicted with the setting of BUILD_INFO=no-info (I wanted to try to support several values for BUILD_INFO: info, no-info and "", where "" would disable more things, but it seems to be too much hassle) So, the attached small patch implements your suggestion, and works as expected: it makeinfo is not available, we now detect problems with tm.texi.in at build time rather than install time. OK? Looking deeper, I realized that texi2dvi and texi2pdf belong to the texinfo package, like makeinfo, so the dvi and pdf rules should probably also depend on BUILD_INFO? To generate html, we call makeinfo --html so the html rules should also depend on BUILD_INFO. However, unlike install-man, the install-html, install-dvi and install-pdf are not part of the plain 'install' target, so maybe we can argue that if someone runs 'make install-pdf' without texinfo, then too bad for him? Thanks, Christophe > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice but > very few check the facts. Think Assange & Stallman. The empires strike back From 7ec6ff8ead24eb7c07d011371347cf12db11faf5 Mon Sep 17 00:00:00 2001 From: Christophe Lyon Date: Sat, 10 Feb 2024 21:17:08 + Subject: [PATCH v3] gcc/Makefile.in: Always check info dependencies BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides MAKEINFO=echo, which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this while testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). As discussed, it is better to detect this problem during 'make all' rather than 'make install', and we still want to detect it even if makeinfo is not available. This patch makes configure set BUILD_INFO=no-info in case makeinfo is missing/too old, which effectively makes the build rules no-ops (x$(BUILD_INFO) != xinfo), and updates Makefile.in so that 'info' dependencies are still checked. 2024-02-10 Christophe Lyon gcc/ * Makefile.in: Add no-info dependency. * configure.ac: Set BUILD_INFO=no-info if makeinfo is not
[PATCH] c++: ICE with reinterpret_cast and switch [PR113545]
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >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
--
2.43.0
[PATCH] c++: Support lambdas attached to FIELD_DECLs in modules [PR111710]
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should I re-introduce the tree checking and just add checks for the
new kinds of declarations that could be have keyed decls?
-- >8 --
The fix for PR107398 weakened the restrictions that lambdas must belong
to namespace scope. However this was not sufficient: we also need to
allow lambdas keyed to FIELD_DECLs or PARM_DECLs.
Because this now requires 'DECL_MODULE_KEYED_DECLS_P' to be checked on a
fairly large number of different kinds of DECLs, and that in general
it's safe to just get 'false' as a result of a check on an unexpected
DECL type, this patch also removes the tree checking from the accessor.
gcc/cp/ChangeLog:
* cp-tree.h (DECL_MODULE_KEYED_DECLS_P): Remove tree checking.
(struct lang_decl_base): Update comments and fix whitespace.
* module.cc (trees_out::lang_decl_bools): Always write
module_keyed_decls_p flag...
(trees_in::lang_decl_bools): ...and always read it.
(trees_out::decl_value): Also handle keyed decls on decls other
than VAR_DECL or FUNCTION_DECL.
(trees_in::decl_value): Likewise.
(trees_out::get_merge_kind): Likewise.
(maybe_key_decl): Also handle lambdas attached to FIELD_DECLs
and PARM_DECLS.
(trees_out::key_mergeable): Likewise.
(trees_in::key_mergeable): Support keyed decls in a TYPE_DECL
container.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-7_a.C: New test.
* g++.dg/modules/lambda-7_b.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/cp-tree.h | 23
gcc/cp/module.cc | 70 +++
gcc/testsuite/g++.dg/modules/lambda-7_a.C | 20 +++
gcc/testsuite/g++.dg/modules/lambda-7_b.C | 16 ++
4 files changed, 81 insertions(+), 48 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/lambda-7_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/lambda-7_b.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 334c11396c2..6ab82dc2d0f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1773,9 +1773,8 @@ check_constraint_info (tree t)
(DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (NODE))->u.base.module_entity_p)
/* DECL that has attached decls for ODR-relatedness. */
-#define DECL_MODULE_KEYED_DECLS_P(NODE)\
- (DECL_LANG_SPECIFIC (TREE_CHECK2(NODE,FUNCTION_DECL,VAR_DECL))\
- ->u.base.module_keyed_decls_p)
+#define DECL_MODULE_KEYED_DECLS_P(NODE) \
+ (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (NODE))->u.base.module_keyed_decls_p)
/* Whether this is an exported DECL. Held on any decl that can appear
at namespace scope (function, var, type, template, const or
@@ -2887,21 +2886,19 @@ struct GTY(()) lang_decl_base {
unsigned friend_or_tls : 1; /* var, fn, type or template */
unsigned unknown_bound_p : 1; /* var */
unsigned odr_used : 1; /* var or fn */
- unsigned concept_p : 1; /* applies to vars and functions */
+ unsigned concept_p : 1; /* applies to vars and functions */
unsigned var_declared_inline_p : 1; /* var */
unsigned dependent_init_p : 1; /* var */
/* The following apply to VAR, FUNCTION, TYPE, CONCEPT, & NAMESPACE
decls. */
- unsigned module_purview_p : 1; // in named-module purview
- unsigned module_attach_p : 1; // attached to named module
- unsigned module_import_p : 1; /* from an import */
- unsigned module_entity_p : 1; /* is in the entitity ary &
- hash. */
- /* VAR_DECL or FUNCTION_DECL has keyed decls. */
- unsigned module_keyed_decls_p : 1;
-
- /* 12 spare bits. */
+ unsigned module_purview_p : 1; /* in named-module purview */
+ unsigned module_attach_p : 1; /* attached to named module
*/
+ unsigned module_import_p : 1; /* from an import */
+ unsigned module_entity_p : 1; /* is in the entitity ary &
hash */
+ unsigned module_keyed_decls_p : 1; /* has keys, applies to all decls */
+
+ /* 11 spare bits. */
};
/* True for DECL codes which have template info and access. */
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 560d8f3b614..9742bca922c 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -5664,8 +5664,7 @@ trees_out::lang_decl_bools (tree t)
want to mark them as in module purview. */
WB (lang->u.base.module_purview_p && !header_module_p ());
WB (lang->u.base.module_attach_p);
- if (VAR_OR_FUNCTION_DECL_P (t))
-WB (lang->u.base.module_keyed_decls_p);
+ WB (lang->u.base.module_keyed_decls_p);
switch (lang->u.base.selector)
{
default:
@@ -5738,8 +5737,7 @@ trees_in::lang_decl_bools (tree t)
RB (lang->u.base.dependent_init_p);
RB (lang->u.base.module_purview_p);
RB (lang->u.
[PATCH] Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268]
Hello,
I have implemented a patch that fixes compile time errors for valid PDT
type-bound procedures. I wrote 4 new tests that address the test-cases in
PR 82943, PR 86148, and PR 86268, since the patch fixes all three of them.
All regression tests pass, including the new ones. This was tested on WSL
2, with Ubuntu 20.04 distro.
Is this okay to push to the trunk?
Alexander Westbrooks
>From 100508673ae26d7fa4ae4f976b4542e115fc7b45 Mon Sep 17 00:00:00 2001
From: Alexander Westbrooks
Date: Sat, 10 Feb 2024 13:19:08 -0600
Subject: [PATCH] Fortran - Error compiling PDT Type-bound Procedures
[PR82943/86148/86268]
This patch allows parameterized derived types to compile successfully
when typebound procedures are specified in the type specification.
Furthermore, it allows function calls for PDTs by setting the
f2k_derived space of PDT instances to reference their original template,
thereby giving it referential access to the typebound procedures of the
template.
2024-02-10 Alexander Westbrooks
gcc/fortran/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* decl.cc (gfc_get_pdt_instance): Set the PDT instance field
'f2k_derived', if not set already, to point to the given
PDT template 'f2k_derived' namespace in order to give the
PDT instance referential access to the typebound procedures
of the template.
* gfortran.h (gfc_pdt_is_instance_of): Add prototype.
* resolve.cc (resolve_typebound_procedure): If the derived type
does not have the attribute 'pdt_template' set, compare the
dummy argument to the 'resolve_bindings_derived' type like usual.
If the derived type is a 'pdt_template', then check if the
dummy argument is an instance of the PDT template. If the derived
type is a PDT template, and the dummy argument is an instance of
that template, but the dummy argument 'param_list' is not
SPEC_ASSUMED, check if there are any LEN parameters in the
dummy argument. If there are no LEN parameters, then this implies
that there are only KIND parameters in the dummy argument.
If there are LEN parameters, this would be an error, for all
LEN parameters for the dummy argument MUST be assumed for
typebound procedures of PDTs.
* symbol.cc (gfc_pdt_is_instance_of): New function.
gcc/testsuite/ChangeLog:
PR fortran/82943
PR fortran/86148
PR fortran/86268
* gfortran.dg/pdt_34.f03: New test.
* gfortran.dg/pdt_35.f03: New test.
* gfortran.dg/pdt_36.f03: New test.
* gfortran.dg/pdt_37.f03: New test.
Signed-off-by: Alexander Westbrooks
---
gcc/fortran/decl.cc | 15 ++
gcc/fortran/gfortran.h | 1 +
gcc/fortran/resolve.cc | 68
gcc/fortran/symbol.cc| 29
gcc/testsuite/gfortran.dg/pdt_34.f03 | 42 +
gcc/testsuite/gfortran.dg/pdt_35.f03 | 45 ++
gcc/testsuite/gfortran.dg/pdt_36.f03 | 65 ++
gcc/testsuite/gfortran.dg/pdt_37.f03 | 34 ++
8 files changed, 291 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pdt_34.f03
create mode 100644 gcc/testsuite/gfortran.dg/pdt_35.f03
create mode 100644 gcc/testsuite/gfortran.dg/pdt_36.f03
create mode 100644 gcc/testsuite/gfortran.dg/pdt_37.f03
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 503ecb8d9b5..c29b2bb0f45 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -4083,6 +4083,21 @@ gfc_get_pdt_instance (gfc_actual_arglist
*param_list, gfc_symbol **sym,
continue;
}
+ /*
+Addressing PR82943, this will fix the issue where a
function/subroutine is declared as not
+a member of the PDT instance. The reason for this is because the PDT
instance did not have
+access to its template's f2k_derived namespace in order to find the
typebound procedures.
+
+The number of references to the PDT template's f2k_derived will ensure
that f2k_derived is
+properly freed later on.
+ */
+
+ if (!instance->f2k_derived && pdt->f2k_derived)
+ {
+instance->f2k_derived = pdt->f2k_derived;
+instance->f2k_derived->refs++;
+ }
+
/* Set the component kind using the parameterized expression. */
if ((c1->ts.kind == 0 || c1->ts.type == BT_CHARACTER)
&& c1->kind_expr != NULL)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index fd73e4ce431..25ff19a6e44 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3585,6 +3585,7 @@ void gfc_traverse_gsymbol (gfc_gsymbol *, void
(*)(gfc_gsymbol *, void *), void
gfc_typebound_proc* gfc_get_typebound_proc (gfc_typebound_proc*);
gfc_symbol* gfc_get_derived_super_type (gfc_symbol*);
bool gfc_type_is_extens
Re: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings
On 2/2/24 23:55, Jonathan Yong wrote: Attached patch OK? Fixes the following warnings: coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n) | ^~ coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__)) | ^~ Copied for review convenience: diff --git a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c index 5684d1b02d4..dadd27eaf41 100644 --- a/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c +++ b/gcc/testsuite/c-c++-common/analyzer/coreutils-sum-pr108666.c @@ -1,6 +1,6 @@ /* Reduced from coreutils's sum.c: bsd_sum_stream */ -typedef long unsigned int size_t; +typedef __SIZE_TYPE__ size_t; typedef unsigned char __uint8_t; typedef unsigned long int __uintmax_t; typedef struct _IO_FILE FILE; Ping?
[PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules
Bootstrapped and regtested (so far just modules.exp and dg.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
(Also I noticed I forgot to add the PR to the changelog in my last
patch, I've fixed that locally.)
-- >8 --
After fixing PR111710, I noticed that we currently ICE when declaring a
type that derives from 'decltype([]{})'. As far as I can tell this
should be legal code, since by [basic.link] p15.2 a lambda defined in a
class-specifier should not be TU-local.
This patch also adds a bunch of tests for unevaluated lambdas in other
contexts, which generally seem to work now.
One interesting case is 'E::f' in the attached testcase: it appears to
get a merge kind of 'MK_field', rather than 'MK_keyed' as most other
lambdas do. I'm not entirely sure if this will cause issues in the
future, but I haven't been able to construct a testcase that causes
problems with this, and conversely wrapping the class body in
'start_lambda_scope' causes issues with symbol duplication in COMDAT
groups, so I've left it as-is for now.
gcc/cp/ChangeLog:
* module.cc (trees_out::key_mergeable): Also support TYPE_DECLs.
(maybe_key_decl): Likewise.
* parser.cc (cp_parser_class_head): Start a lambda scope when
parsing base classes.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-7_a.C:
* g++.dg/modules/lambda-7_b.C:
Signed-off-by: Nathaniel Shead
---
gcc/cp/module.cc | 8 +---
gcc/cp/parser.cc | 10 --
gcc/testsuite/g++.dg/modules/lambda-7_a.C | 19 +++
gcc/testsuite/g++.dg/modules/lambda-7_b.C | 23 +++
4 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 9742bca922c..cceec79b26b 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -10784,7 +10784,8 @@ trees_out::key_mergeable (int tag, merge_kind mk, tree
decl, tree inner,
(TREE_TYPE (inner)));
gcc_checking_assert (TREE_CODE (scope) == VAR_DECL
|| TREE_CODE (scope) == FIELD_DECL
-|| TREE_CODE (scope) == PARM_DECL);
+|| TREE_CODE (scope) == PARM_DECL
+|| TREE_CODE (scope) == TYPE_DECL);
auto *root = keyed_table->get (scope);
unsigned ix = root->length ();
/* If we don't find it, we'll write a really big number
@@ -18980,10 +18981,11 @@ maybe_key_decl (tree ctx, tree decl)
return;
/* We only need to deal with lambdas attached to var, field,
- or parm decls. */
+ parm, or type decls. */
if (TREE_CODE (ctx) != VAR_DECL
&& TREE_CODE (ctx) != FIELD_DECL
- && TREE_CODE (ctx) != PARM_DECL)
+ && TREE_CODE (ctx) != PARM_DECL
+ && TREE_CODE (ctx) != TYPE_DECL)
return;
if (!keyed_table)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 09ecfa23b5d..151e724ed66 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -27663,10 +27663,16 @@ cp_parser_class_head (cp_parser* parser,
if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
{
if (type)
- pushclass (type);
+ {
+ pushclass (type);
+ start_lambda_scope (TYPE_NAME (type));
+ }
bases = cp_parser_base_clause (parser);
if (type)
- popclass ();
+ {
+ finish_lambda_scope ();
+ popclass ();
+ }
}
else
bases = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/modules/lambda-7_a.C
b/gcc/testsuite/g++.dg/modules/lambda-7_a.C
index 289285cd926..9a23827a280 100644
--- a/gcc/testsuite/g++.dg/modules/lambda-7_a.C
+++ b/gcc/testsuite/g++.dg/modules/lambda-7_a.C
@@ -18,3 +18,22 @@ export struct S {
export inline int d(int x, int (*f)(int) = [](int x) { return x * 5; }) {
return f(x);
}
+
+// unevaluated lambdas
+#if __cplusplus >= 202002L
+export struct E : decltype([](int x) { return x * 6; }) {
+ decltype([](int x) { return x * 7; }) f;
+};
+
+export template
+struct G : decltype([](int x) { return x * 8; }) {
+ decltype([](int x) { return x * 9; }) h;
+};
+
+template <>
+struct G : decltype([](int x) { return x * 10; }) {
+ decltype([](int x) { return x * 11; }) i;
+};
+
+export decltype([](int x) { return x * 12; }) j;
+#endif
diff --git a/gcc/testsuite/g++.dg/modules/lambda-7_b.C
b/gcc/testsuite/g++.dg/modules/lambda-7_b.C
index a8762399ee1..59a82e05cbf 100644
--- a/gcc/testsuite/g++.dg/modules/lambda-7_b.C
+++ b/gcc/testsuite/g++.dg/modules/lambda-7_b.C
@@ -13,4 +13,27 @@ int main() {
__builtin_abort();
if (d(10) != 50)
__builtin_abort();
+
+#if __cplusplus >= 202002L
+ E e;
+ if (e(10) != 60)
+__builtin_abort();
+ if (e.f(10) != 70)
+__builtin_abort();
+
+ G g1;
+ if (g1(10) != 80)
+__builtin_abort();
+ if (g1.h(10) != 90)
+__builtin_abort();
+
+ G g2;
+ if (g2(10) != 100)
+__built
Re: [PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules
On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead
wrote:
>
> Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
>
> (Also I noticed I forgot to add the PR to the changelog in my last
> patch, I've fixed that locally.)
>
> -- >8 --
>
> After fixing PR111710, I noticed that we currently ICE when declaring a
> type that derives from 'decltype([]{})'. As far as I can tell this
> should be legal code, since by [basic.link] p15.2 a lambda defined in a
> class-specifier should not be TU-local.
>
> This patch also adds a bunch of tests for unevaluated lambdas in other
> contexts, which generally seem to work now.
There are many unevaluated lambdas (non-modules related) bugs report
(all linked to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430).
Do you know if this fixes any of the non-module related ones too?
Thanks,
Andrew Pinski
>
> One interesting case is 'E::f' in the attached testcase: it appears to
> get a merge kind of 'MK_field', rather than 'MK_keyed' as most other
> lambdas do. I'm not entirely sure if this will cause issues in the
> future, but I haven't been able to construct a testcase that causes
> problems with this, and conversely wrapping the class body in
> 'start_lambda_scope' causes issues with symbol duplication in COMDAT
> groups, so I've left it as-is for now.
>
> gcc/cp/ChangeLog:
>
> * module.cc (trees_out::key_mergeable): Also support TYPE_DECLs.
> (maybe_key_decl): Likewise.
> * parser.cc (cp_parser_class_head): Start a lambda scope when
> parsing base classes.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/lambda-7_a.C:
> * g++.dg/modules/lambda-7_b.C:
>
> Signed-off-by: Nathaniel Shead
> ---
> gcc/cp/module.cc | 8 +---
> gcc/cp/parser.cc | 10 --
> gcc/testsuite/g++.dg/modules/lambda-7_a.C | 19 +++
> gcc/testsuite/g++.dg/modules/lambda-7_b.C | 23 +++
> 4 files changed, 55 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 9742bca922c..cceec79b26b 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -10784,7 +10784,8 @@ trees_out::key_mergeable (int tag, merge_kind mk,
> tree decl, tree inner,
> (TREE_TYPE (inner)));
> gcc_checking_assert (TREE_CODE (scope) == VAR_DECL
> || TREE_CODE (scope) == FIELD_DECL
> -|| TREE_CODE (scope) == PARM_DECL);
> +|| TREE_CODE (scope) == PARM_DECL
> +|| TREE_CODE (scope) == TYPE_DECL);
> auto *root = keyed_table->get (scope);
> unsigned ix = root->length ();
> /* If we don't find it, we'll write a really big number
> @@ -18980,10 +18981,11 @@ maybe_key_decl (tree ctx, tree decl)
> return;
>
>/* We only need to deal with lambdas attached to var, field,
> - or parm decls. */
> + parm, or type decls. */
>if (TREE_CODE (ctx) != VAR_DECL
>&& TREE_CODE (ctx) != FIELD_DECL
> - && TREE_CODE (ctx) != PARM_DECL)
> + && TREE_CODE (ctx) != PARM_DECL
> + && TREE_CODE (ctx) != TYPE_DECL)
> return;
>
>if (!keyed_table)
> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> index 09ecfa23b5d..151e724ed66 100644
> --- a/gcc/cp/parser.cc
> +++ b/gcc/cp/parser.cc
> @@ -27663,10 +27663,16 @@ cp_parser_class_head (cp_parser* parser,
>if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
> {
>if (type)
> - pushclass (type);
> + {
> + pushclass (type);
> + start_lambda_scope (TYPE_NAME (type));
> + }
>bases = cp_parser_base_clause (parser);
>if (type)
> - popclass ();
> + {
> + finish_lambda_scope ();
> + popclass ();
> + }
> }
>else
> bases = NULL_TREE;
> diff --git a/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> b/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> index 289285cd926..9a23827a280 100644
> --- a/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> +++ b/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> @@ -18,3 +18,22 @@ export struct S {
> export inline int d(int x, int (*f)(int) = [](int x) { return x * 5; }) {
>return f(x);
> }
> +
> +// unevaluated lambdas
> +#if __cplusplus >= 202002L
> +export struct E : decltype([](int x) { return x * 6; }) {
> + decltype([](int x) { return x * 7; }) f;
> +};
> +
> +export template
> +struct G : decltype([](int x) { return x * 8; }) {
> + decltype([](int x) { return x * 9; }) h;
> +};
> +
> +template <>
> +struct G : decltype([](int x) { return x * 10; }) {
> + decltype([](int x) { return x * 11; }) i;
> +};
> +
> +export decltype([](int x) { return x * 12; }) j;
> +#endif
> diff --git a/gcc/testsuite/g++.dg/modules/lambda-7_b.C
> b/gcc/testsuite/g++.dg/modules
Re: [PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules
On Sat, Feb 10, 2024 at 08:01:46PM -0800, Andrew Pinski wrote:
> On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead
> wrote:
> >
> > Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
> >
> > (Also I noticed I forgot to add the PR to the changelog in my last
> > patch, I've fixed that locally.)
> >
> > -- >8 --
> >
> > After fixing PR111710, I noticed that we currently ICE when declaring a
> > type that derives from 'decltype([]{})'. As far as I can tell this
> > should be legal code, since by [basic.link] p15.2 a lambda defined in a
> > class-specifier should not be TU-local.
> >
> > This patch also adds a bunch of tests for unevaluated lambdas in other
> > contexts, which generally seem to work now.
>
> There are many unevaluated lambdas (non-modules related) bugs report
> (all linked to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430).
> Do you know if this fixes any of the non-module related ones too?
>
> Thanks,
> Andrew Pinski
>
I took a quick look at the issues linked to the above. I tried a few and
they don't seem to be fixed with these patches; in general I would only
expect changes in modules or potentially with lambdas being used in base
class specifiers, neither of which seem particularly relevant to those
issues.
Nathaniel
> >
> > One interesting case is 'E::f' in the attached testcase: it appears to
> > get a merge kind of 'MK_field', rather than 'MK_keyed' as most other
> > lambdas do. I'm not entirely sure if this will cause issues in the
> > future, but I haven't been able to construct a testcase that causes
> > problems with this, and conversely wrapping the class body in
> > 'start_lambda_scope' causes issues with symbol duplication in COMDAT
> > groups, so I've left it as-is for now.
> >
> > gcc/cp/ChangeLog:
> >
> > * module.cc (trees_out::key_mergeable): Also support TYPE_DECLs.
> > (maybe_key_decl): Likewise.
> > * parser.cc (cp_parser_class_head): Start a lambda scope when
> > parsing base classes.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/modules/lambda-7_a.C:
> > * g++.dg/modules/lambda-7_b.C:
> >
> > Signed-off-by: Nathaniel Shead
> > ---
> > gcc/cp/module.cc | 8 +---
> > gcc/cp/parser.cc | 10 --
> > gcc/testsuite/g++.dg/modules/lambda-7_a.C | 19 +++
> > gcc/testsuite/g++.dg/modules/lambda-7_b.C | 23 +++
> > 4 files changed, 55 insertions(+), 5 deletions(-)
> >
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index 9742bca922c..cceec79b26b 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -10784,7 +10784,8 @@ trees_out::key_mergeable (int tag, merge_kind mk,
> > tree decl, tree inner,
> > (TREE_TYPE (inner)));
> > gcc_checking_assert (TREE_CODE (scope) == VAR_DECL
> > || TREE_CODE (scope) == FIELD_DECL
> > -|| TREE_CODE (scope) == PARM_DECL);
> > +|| TREE_CODE (scope) == PARM_DECL
> > +|| TREE_CODE (scope) == TYPE_DECL);
> > auto *root = keyed_table->get (scope);
> > unsigned ix = root->length ();
> > /* If we don't find it, we'll write a really big number
> > @@ -18980,10 +18981,11 @@ maybe_key_decl (tree ctx, tree decl)
> > return;
> >
> >/* We only need to deal with lambdas attached to var, field,
> > - or parm decls. */
> > + parm, or type decls. */
> >if (TREE_CODE (ctx) != VAR_DECL
> >&& TREE_CODE (ctx) != FIELD_DECL
> > - && TREE_CODE (ctx) != PARM_DECL)
> > + && TREE_CODE (ctx) != PARM_DECL
> > + && TREE_CODE (ctx) != TYPE_DECL)
> > return;
> >
> >if (!keyed_table)
> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > index 09ecfa23b5d..151e724ed66 100644
> > --- a/gcc/cp/parser.cc
> > +++ b/gcc/cp/parser.cc
> > @@ -27663,10 +27663,16 @@ cp_parser_class_head (cp_parser* parser,
> >if (cp_lexer_next_token_is (parser->lexer, CPP_COLON))
> > {
> >if (type)
> > - pushclass (type);
> > + {
> > + pushclass (type);
> > + start_lambda_scope (TYPE_NAME (type));
> > + }
> >bases = cp_parser_base_clause (parser);
> >if (type)
> > - popclass ();
> > + {
> > + finish_lambda_scope ();
> > + popclass ();
> > + }
> > }
> >else
> > bases = NULL_TREE;
> > diff --git a/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> > b/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> > index 289285cd926..9a23827a280 100644
> > --- a/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> > +++ b/gcc/testsuite/g++.dg/modules/lambda-7_a.C
> > @@ -18,3 +18,22 @@ export struct S {
> > export inline int d(int x, int (*f)(int) = [](int x) { return x * 5; }) {
> >r
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
Hello, Christophe, On Feb 10, 2024, Christophe Lyon wrote: > gcc/ > * Makefile.in: Add no-info dependency. > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > available. > * configure: Regenerate. Thank you, this is ok. Now, this doesn't fix a regression, does it? I would support putting this in for GCC 14, but I would be overstepping my authority if I approved even such a small and well-contained improvement patch in the current stage, so I'm approving it for stage1, but maybe some global maintainer or release manager will chime in in support for earlier merging? (hint, hint ;-) -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Think Assange & Stallman. The empires strike back
