Re: [C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Jakub Jelinek]

On Sun, Apr 14, 2024 at 02:30:27PM +0200, Martin Uecker wrote:
> 2024-04-12  Martin Uecker  
>   Jakub Jelinek  
> 
>   PR lto/114574
>   PR c/114361
> gcc/
>   * ipa-free-lang-data.cc (fld_incomplete_type_of): Allow
>   either of the types in the assert to have TYPE_STRUCTURAL_EQUALITY_P.
> gcc/c/
>   * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not
>   ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY.
>   (parser_xref_tag): Likewise.
>   (start_struct): For flag_isoc23 use SET_TYPE_STRUCTURAL_EQUALITY.
>   (c_update_type_canonical): New function.
>   (finish_struct): Put NULL as second == operand rather than first.
>   Assert TYPE_STRUCTURAL_EQUALITY_P.  Call c_update_type_canonical.
>   * c-typeck.cc (composite_type_internal): Use
>   SET_TYPE_STRUCTURAL_EQUALITY.  Formatting fix.
> gcc/testsuite/
>   * gcc.dg/pr114574-1.c: New test.
>   * gcc.dg/pr114574-2.c: New test.
>   * gcc.dg/pr114361.c: New test.
>   * gcc.dg/c23-tag-incomplete-1.c: New test.
>   * gcc.dg/c23-tag-incomplete-2.c: New test.

Just a nit I haven't seen before (not a review, can't do that when
I've participated on the patch):

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c23-tag-incomplete-1.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile }
> + * { dg-options "-std=c23 -g" } */
> +
> +struct a;
> +typedef struct a b;
> +
> +void g() {
> +struct a { b* x; };
> +}
> +
> +struct a { b* x; };
> +
> +
> +

Please avoid the trailing whitespace in the testcases.  They should end with
a single newline, not 3-4 newlines.

Jakub

Re: [C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 08:55:56AM +0200, Richard Biener wrote:
> > diff --git a/gcc/ipa-free-lang-data.cc b/gcc/ipa-free-lang-data.cc
> > index 16ed55e2e5a..6f75444e513 100644
> > --- a/gcc/ipa-free-lang-data.cc
> > +++ b/gcc/ipa-free-lang-data.cc
> > @@ -255,7 +255,9 @@ fld_incomplete_type_of (tree t, class free_lang_data_d 
> > *fld)
> > first = build_reference_type_for_mode (t2, TYPE_MODE (t),
> >TYPE_REF_CAN_ALIAS_ALL (t));
> >   gcc_assert (TYPE_CANONICAL (t2) != t2
> > - && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t)));
> > + && (TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))
> > + || TYPE_STRUCTURAL_EQUALITY_P (t2)
> > + || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (t;
> 
> I think we want the same canonical types for t2 and TREE_TYPE (t), why
> doesn't fld_incomplete_type_of make it so?

I had this spot instrumented to log the different cases (before adding the
code to fix up also pointer types in c_update_type_canonical) and the only thing
that triggered was that the 2 TYPE_CANONICALs weren't equal if
TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (t)), the other was just in case.
gcc.c-torture/compile/20021205-1.c
gcc.c-torture/compile/20040214-2.c
gcc.c-torture/compile/20060109-1.c
gcc.c-torture/compile/pr113623.c
gcc.c-torture/compile/pr46866.c
gcc.c-torture/compile/pta-1.c
gcc.c-torture/execute/pr33870-1.c
gcc.c-torture/execute/pr33870.c
gcc.dg/torture/pr57478.c
tests were affected in make check-gcc.
I thought it would be a clear consequence of the choice we've discussed on
IRC, that build_pointer_type_for_mode and other tree.cc functions which
lookup/create derived types don't try to fill in TYPE_CANONICAL for
types derived from something which initially had TYPE_STRUCTURAL_EQUALITY_P
but later changed to non-TYPE_STRUCTURAL_EQUALITY_P.  The patch updates
it solely for qualified types/related pointer types, but doesn't do that
for array types, pointer to array types, function types, ...
So, I think the assertion could still trigger if we have something like
-O2 -flto -std=c23
struct S;
typedef struct S *T;
typedef T U[10];
typedef U *V;
V foo (int x) { return 0; }
struct S { int s; };
(but doesn't, dunno what I'm missing; though here certainly V and U have
TYPE_STRUCTURAL_EQUALITY_P, even T has because it is a typedef, not
something actually normally returned by build_pointer_type).

Jakub

Re: [C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 09:38:29AM +0200, Jakub Jelinek wrote:
> I had this spot instrumented to log the different cases (before adding the
> code to fix up also pointer types in c_update_type_canonical) and the only 
> thing
> that triggered was that the 2 TYPE_CANONICALs weren't equal if
> TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (t)), the other was just in case.
> gcc.c-torture/compile/20021205-1.c
> gcc.c-torture/compile/20040214-2.c
> gcc.c-torture/compile/20060109-1.c
> gcc.c-torture/compile/pr113623.c
> gcc.c-torture/compile/pr46866.c
> gcc.c-torture/compile/pta-1.c
> gcc.c-torture/execute/pr33870-1.c
> gcc.c-torture/execute/pr33870.c
> gcc.dg/torture/pr57478.c
> tests were affected in make check-gcc.
> I thought it would be a clear consequence of the choice we've discussed on
> IRC, that build_pointer_type_for_mode and other tree.cc functions which
> lookup/create derived types don't try to fill in TYPE_CANONICAL for
> types derived from something which initially had TYPE_STRUCTURAL_EQUALITY_P
> but later changed to non-TYPE_STRUCTURAL_EQUALITY_P.  The patch updates
> it solely for qualified types/related pointer types, but doesn't do that
> for array types, pointer to array types, function types, ...
> So, I think the assertion could still trigger if we have something like
> -O2 -flto -std=c23
> struct S;
> typedef struct S *T;
> typedef T U[10];
> typedef U *V;
> V foo (int x) { return 0; }
> struct S { int s; };
> (but doesn't, dunno what I'm missing; though here certainly V and U have
> TYPE_STRUCTURAL_EQUALITY_P, even T has because it is a typedef, not
> something actually normally returned by build_pointer_type).

Though, haven't managed to reproduce it with -O2 -flto -std=c23
struct S;
typedef struct S **V[10];
V **foo (int x) { return 0; }
struct S { int s; };
either.
So, maybe let's drop the ipa-free-lang-data.cc part?
Seems fld_incomplete_type_of uses fld_type_variant which should
copy over TYPE_CANONICAL.

Jakub

Re: [C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Richard Biener]

On Mon, 15 Apr 2024, Jakub Jelinek wrote:

> On Mon, Apr 15, 2024 at 09:38:29AM +0200, Jakub Jelinek wrote:
> > I had this spot instrumented to log the different cases (before adding the
> > code to fix up also pointer types in c_update_type_canonical) and the only 
> > thing
> > that triggered was that the 2 TYPE_CANONICALs weren't equal if
> > TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (t)), the other was just in case.
> > gcc.c-torture/compile/20021205-1.c
> > gcc.c-torture/compile/20040214-2.c
> > gcc.c-torture/compile/20060109-1.c
> > gcc.c-torture/compile/pr113623.c
> > gcc.c-torture/compile/pr46866.c
> > gcc.c-torture/compile/pta-1.c
> > gcc.c-torture/execute/pr33870-1.c
> > gcc.c-torture/execute/pr33870.c
> > gcc.dg/torture/pr57478.c
> > tests were affected in make check-gcc.
> > I thought it would be a clear consequence of the choice we've discussed on
> > IRC, that build_pointer_type_for_mode and other tree.cc functions which
> > lookup/create derived types don't try to fill in TYPE_CANONICAL for
> > types derived from something which initially had TYPE_STRUCTURAL_EQUALITY_P
> > but later changed to non-TYPE_STRUCTURAL_EQUALITY_P.  The patch updates
> > it solely for qualified types/related pointer types, but doesn't do that
> > for array types, pointer to array types, function types, ...
> > So, I think the assertion could still trigger if we have something like
> > -O2 -flto -std=c23
> > struct S;
> > typedef struct S *T;
> > typedef T U[10];
> > typedef U *V;
> > V foo (int x) { return 0; }
> > struct S { int s; };
> > (but doesn't, dunno what I'm missing; though here certainly V and U have
> > TYPE_STRUCTURAL_EQUALITY_P, even T has because it is a typedef, not
> > something actually normally returned by build_pointer_type).
> 
> Though, haven't managed to reproduce it with -O2 -flto -std=c23
> struct S;
> typedef struct S **V[10];
> V **foo (int x) { return 0; }
> struct S { int s; };
> either.
> So, maybe let's drop the ipa-free-lang-data.cc part?
> Seems fld_incomplete_type_of uses fld_type_variant which should
> copy over TYPE_CANONICAL.

If you have a testcase that still triggers it would be nice to see it.

Richard.

[PATCH] attribs: Don't crash on NULL TREE_TYPE in diag_attr_exclusions [PR114634]

[Jakub Jelinek]

Hi!

The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions
assumes that all decls must have types.
I think it is better in something as unimportant as diag_attr_exclusions
to be more robust, if there is no type, it can just diagnose exclusions
on the DECL_ATTRIBUTES, like for types it only diagnoses it on
TYPE_ATTRIBUTES.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-04-15  Jakub Jelinek  

PR c++/114634
* attribs.cc (diag_attr_exclusions): Set attrs[1] to NULL_TREE for
decls with NULL TREE_TYPE.

* g++.dg/ext/attrib68.C: New test.

--- gcc/attribs.cc.jj   2024-02-12 20:44:52.409074876 +0100
+++ gcc/attribs.cc  2024-04-12 18:29:52.000381917 +0200
@@ -468,7 +468,10 @@ diag_attr_exclusions (tree last_decl, tr
   if (DECL_P (node))
 {
   attrs[0] = DECL_ATTRIBUTES (node);
-  attrs[1] = TYPE_ATTRIBUTES (TREE_TYPE (node));
+  if (TREE_TYPE (node))
+   attrs[1] = TYPE_ATTRIBUTES (TREE_TYPE (node));
+  else
+   attrs[1] = NULL_TREE;
 }
   else
 {
--- gcc/testsuite/g++.dg/ext/attrib68.C.jj  2024-04-12 18:31:38.100968098 
+0200
+++ gcc/testsuite/g++.dg/ext/attrib68.C 2024-04-12 18:30:57.011515625 +0200
@@ -0,0 +1,8 @@
+// PR c++/114634
+// { dg-do compile }
+
+template 
+struct A
+{
+  enum { e __attribute__ ((aligned (16))) };   // { dg-error "alignment may 
not be specified for 'e'" }
+};

Jakub

Re: [C PATCH, v2] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > struct S;
> > typedef struct S **V[10];
> > V **foo (int x) { return 0; }
> > struct S { int s; };
> > either.
> > So, maybe let's drop the ipa-free-lang-data.cc part?
> > Seems fld_incomplete_type_of uses fld_type_variant which should
> > copy over TYPE_CANONICAL.
> 
> If you have a testcase that still triggers it would be nice to see it.

I don't, that is why I'm now suggesting to just drop that hunk.

Jakub

Re: [PATCH] attribs: Don't crash on NULL TREE_TYPE in diag_attr_exclusions [PR114634]

[Richard Biener]

On Mon, 15 Apr 2024, Jakub Jelinek wrote:

> Hi!
> 
> The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions
> assumes that all decls must have types.
> I think it is better in something as unimportant as diag_attr_exclusions
> to be more robust, if there is no type, it can just diagnose exclusions
> on the DECL_ATTRIBUTES, like for types it only diagnoses it on
> TYPE_ATTRIBUTES.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK, but can you add a comment?

Thanks,
Richard.

> 2024-04-15  Jakub Jelinek  
> 
>   PR c++/114634
>   * attribs.cc (diag_attr_exclusions): Set attrs[1] to NULL_TREE for
>   decls with NULL TREE_TYPE.
> 
>   * g++.dg/ext/attrib68.C: New test.
> 
> --- gcc/attribs.cc.jj 2024-02-12 20:44:52.409074876 +0100
> +++ gcc/attribs.cc2024-04-12 18:29:52.000381917 +0200
> @@ -468,7 +468,10 @@ diag_attr_exclusions (tree last_decl, tr
>if (DECL_P (node))
>  {
>attrs[0] = DECL_ATTRIBUTES (node);
> -  attrs[1] = TYPE_ATTRIBUTES (TREE_TYPE (node));
> +  if (TREE_TYPE (node))
> + attrs[1] = TYPE_ATTRIBUTES (TREE_TYPE (node));
> +  else
> + attrs[1] = NULL_TREE;
>  }
>else
>  {
> --- gcc/testsuite/g++.dg/ext/attrib68.C.jj2024-04-12 18:31:38.100968098 
> +0200
> +++ gcc/testsuite/g++.dg/ext/attrib68.C   2024-04-12 18:30:57.011515625 
> +0200
> @@ -0,0 +1,8 @@
> +// PR c++/114634
> +// { dg-do compile }
> +
> +template 
> +struct A
> +{
> +  enum { e __attribute__ ((aligned (16))) }; // { dg-error "alignment may 
> not be specified for 'e'" }
> +};
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

[Rainer Orth]

Hi Jørgen,

> On 04/04/2024 14:10, Jan Hubicka wrote:
>>> gcc/ChangeLog:
>>>
>>> * builtins.cc (expand_builtin_fork_or_exec): Check
>>>   condition_coverage_flag.
>>> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
>>> * common.opt: Add new options -fcondition-coverage and
>>>   -Wcoverage-too-many-conditions.
>>> * doc/gcov.texi: Add --conditions documentation.
>>> * doc/invoke.texi: Add -fcondition-coverage documentation.
>>> * function.cc (free_after_compilation): Free cond_uids.
>>> * function.h (struct function): Add cond_uids.
>>> * gcc.cc: Link gcov on -fcondition-coverage.
>>> * gcov-counter.def (GCOV_COUNTER_CONDS): New.
>>> * gcov-dump.cc (tag_conditions): New.
>>> * gcov-io.h (GCOV_TAG_CONDS): New.
>>> (GCOV_TAG_CONDS_LENGTH): New.
>>> (GCOV_TAG_CONDS_NUM): New.
>>> * gcov.cc (class condition_info): New.
>>> (condition_info::condition_info): New.
>>> (condition_info::popcount): New.
>>> (struct coverage_info): New.
>>> (add_condition_counts): New.
>>> (output_conditions): New.
>>> (print_usage): Add -g, --conditions.
>>> (process_args): Likewise.
>>> (output_intermediate_json_line): Output conditions.
>>> (read_graph_file): Read condition counters.
>>> (read_count_file): Likewise.
>>> (file_summary): Print conditions.
>>> (accumulate_line_info): Accumulate conditions.
>>> (output_line_details): Print conditions.
>>> * gimplify.cc (next_cond_uid): New.
>>> (reset_cond_uid): New.
>>> (shortcut_cond_r): Set condition discriminator.
>>> (tag_shortcut_cond): New.
>>> (gimple_associate_condition_with_expr): New.
>>> (shortcut_cond_expr): Set condition discriminator.
>>> (gimplify_cond_expr): Likewise.
>>> (gimplify_function_tree): Call reset_cond_uid.
>>> * ipa-inline.cc (can_early_inline_edge_p): Check
>>>   condition_coverage_flag.
>>> * ipa-split.cc (pass_split_functions::gate): Likewise.
>>> * passes.cc (finish_optimization_passes): Likewise.
>>> * profile.cc (struct condcov): New declaration.
>>> (cov_length): Likewise.
>>> (cov_blocks): Likewise.
>>> (cov_masks): Likewise.
>>> (cov_maps): Likewise.
>>> (cov_free): Likewise.
>>> (instrument_decisions): New.
>>> (read_thunk_profile): Control output to file.
>>> (branch_prob): Call find_conditions, instrument_decisions.
>>> (init_branch_prob): Add total_num_conds.
>>> (end_branch_prob): Likewise.
>>> * tree-core.h (struct tree_exp): Add condition_uid.
>>> * tree-profile.cc (struct conds_ctx): New.
>>> (CONDITIONS_MAX_TERMS): New.
>>> (EDGE_CONDITION): New.
>>> (topological_cmp): New.
>>> (index_of): New.
>>> (single_p): New.
>>> (single_edge): New.
>>> (contract_edge_up): New.
>>> (struct outcomes): New.
>>> (conditional_succs): New.
>>> (condition_index): New.
>>> (condition_uid): New.
>>> (masking_vectors): New.
>>> (emit_assign): New.
>>> (emit_bitwise_op): New.
>>> (make_top_index_visit): New.
>>> (make_top_index): New.
>>> (paths_between): New.
>>> (struct condcov): New.
>>> (cov_length): New.
>>> (cov_blocks): New.
>>> (cov_masks): New.
>>> (cov_maps): New.
>>> (cov_free): New.
>>> (find_conditions): New.
>>> (struct counters): New.
>>> (find_counters): New.
>>> (resolve_counter): New.
>>> (resolve_counters): New.
>>> (instrument_decisions): New.
>>> (tree_profiling): Check condition_coverage_flag.
>>> (pass_ipa_tree_profile::gate): Likewise.
>>> * tree.h (SET_EXPR_UID): New.
>>> (EXPR_COND_UID): New.
>>>
>>> libgcc/ChangeLog:
>>>
>>> * libgcov-merge.c (__gcov_merge_ior): New.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * lib/gcov.exp: Add condition coverage test function.
>>> * g++.dg/gcov/gcov-18.C: New test.
>>> * gcc.misc-tests/gcov-19.c: New test.
>>> * gcc.misc-tests/gcov-20.c: New test.
>>> * gcc.misc-tests/gcov-21.c: New test.
>>> * gcc.misc-tests/gcov-22.c: New test.
>>> * gcc.misc-tests/gcov-23.c: New test.
>>> ---
>>>   gcc/builtins.cc|2 +-
>>>   gcc/collect2.cc|7 +-
>>>   gcc/common.opt |9 +
>>>   gcc/doc/gcov.texi  |   38 +
>>>   gcc/doc/invoke.texi|   21 +
>>>   gcc/function.cc|1 +
>>>   gcc/function.h |4 +
>>>   gcc/gcc.cc |4 +-
>>>   gcc/gcov-counter.def   |3 +
>>>   gcc/gcov-dump.cc   |   24 +
>>>   gcc/gcov-io.h  |3 +
>>>   gcc/gcov.cc|  209 ++-
>>>   gcc/gimplify.cc|  123 +-
>>>   gcc/ipa-inline.cc  |2 +-
>>>   gcc/ipa-split.cc   |2 +-
>>>   gcc/passes.cc 

Re: [PATCH 1/2] Remove unecessary and broken MC/DC compile test

[Rainer Orth]

Hi Jørgen,

> The __sigsetjmp test was added as a regression test, which an early
> iteration of the MC/DC support caused an internal compiler error,
> triggered by a code path which did not make it through to the final
> revision.  Since this test really only worked on linux and does not
> serve a purpose any more it can be removed.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.misc-tests/gcov-19.c: Remove test.

just a nit (and too late since it's already checked in): the ChangeLog
entry should specify *which test* was removed.  As is, it reads like the
whole file has been removed.  Something like

* gcc.misc-tests/gcov-19.c (__sigsetjmp, mcdc021c): Remove.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

[Jørgen Kvalsvik]

On 15/04/2024 10:53, Rainer Orth wrote:

Hi Jørgen,


On 04/04/2024 14:10, Jan Hubicka wrote:

gcc/ChangeLog:

* builtins.cc (expand_builtin_fork_or_exec): Check
  condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt: Add new options -fcondition-coverage and
  -Wcoverage-too-many-conditions.
* doc/gcov.texi: Add --conditions documentation.
* doc/invoke.texi: Add -fcondition-coverage documentation.
* function.cc (free_after_compilation): Free cond_uids.
* function.h (struct function): Add cond_uids.
* gcc.cc: Link gcov on -fcondition-coverage.
* gcov-counter.def (GCOV_COUNTER_CONDS): New.
* gcov-dump.cc (tag_conditions): New.
* gcov-io.h (GCOV_TAG_CONDS): New.
(GCOV_TAG_CONDS_LENGTH): New.
(GCOV_TAG_CONDS_NUM): New.
* gcov.cc (class condition_info): New.
(condition_info::condition_info): New.
(condition_info::popcount): New.
(struct coverage_info): New.
(add_condition_counts): New.
(output_conditions): New.
(print_usage): Add -g, --conditions.
(process_args): Likewise.
(output_intermediate_json_line): Output conditions.
(read_graph_file): Read condition counters.
(read_count_file): Likewise.
(file_summary): Print conditions.
(accumulate_line_info): Accumulate conditions.
(output_line_details): Print conditions.
* gimplify.cc (next_cond_uid): New.
(reset_cond_uid): New.
(shortcut_cond_r): Set condition discriminator.
(tag_shortcut_cond): New.
(gimple_associate_condition_with_expr): New.
(shortcut_cond_expr): Set condition discriminator.
(gimplify_cond_expr): Likewise.
(gimplify_function_tree): Call reset_cond_uid.
* ipa-inline.cc (can_early_inline_edge_p): Check
  condition_coverage_flag.
* ipa-split.cc (pass_split_functions::gate): Likewise.
* passes.cc (finish_optimization_passes): Likewise.
* profile.cc (struct condcov): New declaration.
(cov_length): Likewise.
(cov_blocks): Likewise.
(cov_masks): Likewise.
(cov_maps): Likewise.
(cov_free): Likewise.
(instrument_decisions): New.
(read_thunk_profile): Control output to file.
(branch_prob): Call find_conditions, instrument_decisions.
(init_branch_prob): Add total_num_conds.
(end_branch_prob): Likewise.
* tree-core.h (struct tree_exp): Add condition_uid.
* tree-profile.cc (struct conds_ctx): New.
(CONDITIONS_MAX_TERMS): New.
(EDGE_CONDITION): New.
(topological_cmp): New.
(index_of): New.
(single_p): New.
(single_edge): New.
(contract_edge_up): New.
(struct outcomes): New.
(conditional_succs): New.
(condition_index): New.
(condition_uid): New.
(masking_vectors): New.
(emit_assign): New.
(emit_bitwise_op): New.
(make_top_index_visit): New.
(make_top_index): New.
(paths_between): New.
(struct condcov): New.
(cov_length): New.
(cov_blocks): New.
(cov_masks): New.
(cov_maps): New.
(cov_free): New.
(find_conditions): New.
(struct counters): New.
(find_counters): New.
(resolve_counter): New.
(resolve_counters): New.
(instrument_decisions): New.
(tree_profiling): Check condition_coverage_flag.
(pass_ipa_tree_profile::gate): Likewise.
* tree.h (SET_EXPR_UID): New.
(EXPR_COND_UID): New.

libgcc/ChangeLog:

* libgcov-merge.c (__gcov_merge_ior): New.

gcc/testsuite/ChangeLog:

* lib/gcov.exp: Add condition coverage test function.
* g++.dg/gcov/gcov-18.C: New test.
* gcc.misc-tests/gcov-19.c: New test.
* gcc.misc-tests/gcov-20.c: New test.
* gcc.misc-tests/gcov-21.c: New test.
* gcc.misc-tests/gcov-22.c: New test.
* gcc.misc-tests/gcov-23.c: New test.
---
   gcc/builtins.cc|2 +-
   gcc/collect2.cc|7 +-
   gcc/common.opt |9 +
   gcc/doc/gcov.texi  |   38 +
   gcc/doc/invoke.texi|   21 +
   gcc/function.cc|1 +
   gcc/function.h |4 +
   gcc/gcc.cc |4 +-
   gcc/gcov-counter.def   |3 +
   gcc/gcov-dump.cc   |   24 +
   gcc/gcov-io.h  |3 +
   gcc/gcov.cc|  209 ++-
   gcc/gimplify.cc|  123 +-
   gcc/ipa-inline.cc  |2 +-
   gcc/ipa-split.cc   |2 +-
   gcc/passes.cc  |3 +-
   gcc/profile

[COMMITTED] testsuite: i386: Restrict gcc.target/i386/fhardened-1.c etc. to Linux/GNU

[Rainer Orth]

The new gcc.target/i386/fhardened-1.c etc. tests FAIL on Solaris/x86 and
Darwin/x86:

FAIL: gcc.target/i386/fhardened-1.c (test for excess errors)
FAIL: gcc.target/i386/fhardened-2.c (test for excess errors)

Excess errors: 
cc1: warning: '-fhardened' not supported for this target

Support for -fhardened is restricted to HAVE_FHARDENED_SUPPORT in
toplev.cc (process_options) which again is only defined for linux*|gnu*
targets in gcc/configure.ac.

Accordingly, this patch restricts the tests to those two, as is already
done in gcc.target/i386/cf_check-6.c.

Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.  Committed to
trunk.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2024-04-15  Rainer Orth  

gcc/testsuite:
* gcc.target/i386/fhardened-1.c: Restrict to Linux/GNU.
* gcc.target/i386/fhardened-2.c: Likewise.

# HG changeset patch
# Parent  270ceb327b3c4010c7f88cc77b599ddb43896640
testsuite: i386: Restrict gcc.target/i386/fhardened-1.c etc. to Linux/GNU

diff --git a/gcc/testsuite/gcc.target/i386/fhardened-1.c b/gcc/testsuite/gcc.target/i386/fhardened-1.c
--- a/gcc/testsuite/gcc.target/i386/fhardened-1.c
+++ b/gcc/testsuite/gcc.target/i386/fhardened-1.c
@@ -1,4 +1,5 @@
 /* PR target/114606 */
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
 /* { dg-options "-fhardened -O2 -fcf-protection=none" } */
 
 #ifdef __CET__
diff --git a/gcc/testsuite/gcc.target/i386/fhardened-2.c b/gcc/testsuite/gcc.target/i386/fhardened-2.c
--- a/gcc/testsuite/gcc.target/i386/fhardened-2.c
+++ b/gcc/testsuite/gcc.target/i386/fhardened-2.c
@@ -1,4 +1,5 @@
 /* PR target/114606 */
+/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
 /* { dg-options "-fhardened -O2" } */
 
 #if __CET__ != 3

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

[Jørgen Kvalsvik]

On 15/04/2024 10:53, Rainer Orth wrote:

Hi Jørgen,


On 04/04/2024 14:10, Jan Hubicka wrote:

gcc/ChangeLog:

* builtins.cc (expand_builtin_fork_or_exec): Check
  condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt: Add new options -fcondition-coverage and
  -Wcoverage-too-many-conditions.
* doc/gcov.texi: Add --conditions documentation.
* doc/invoke.texi: Add -fcondition-coverage documentation.
* function.cc (free_after_compilation): Free cond_uids.
* function.h (struct function): Add cond_uids.
* gcc.cc: Link gcov on -fcondition-coverage.
* gcov-counter.def (GCOV_COUNTER_CONDS): New.
* gcov-dump.cc (tag_conditions): New.
* gcov-io.h (GCOV_TAG_CONDS): New.
(GCOV_TAG_CONDS_LENGTH): New.
(GCOV_TAG_CONDS_NUM): New.
* gcov.cc (class condition_info): New.
(condition_info::condition_info): New.
(condition_info::popcount): New.
(struct coverage_info): New.
(add_condition_counts): New.
(output_conditions): New.
(print_usage): Add -g, --conditions.
(process_args): Likewise.
(output_intermediate_json_line): Output conditions.
(read_graph_file): Read condition counters.
(read_count_file): Likewise.
(file_summary): Print conditions.
(accumulate_line_info): Accumulate conditions.
(output_line_details): Print conditions.
* gimplify.cc (next_cond_uid): New.
(reset_cond_uid): New.
(shortcut_cond_r): Set condition discriminator.
(tag_shortcut_cond): New.
(gimple_associate_condition_with_expr): New.
(shortcut_cond_expr): Set condition discriminator.
(gimplify_cond_expr): Likewise.
(gimplify_function_tree): Call reset_cond_uid.
* ipa-inline.cc (can_early_inline_edge_p): Check
  condition_coverage_flag.
* ipa-split.cc (pass_split_functions::gate): Likewise.
* passes.cc (finish_optimization_passes): Likewise.
* profile.cc (struct condcov): New declaration.
(cov_length): Likewise.
(cov_blocks): Likewise.
(cov_masks): Likewise.
(cov_maps): Likewise.
(cov_free): Likewise.
(instrument_decisions): New.
(read_thunk_profile): Control output to file.
(branch_prob): Call find_conditions, instrument_decisions.
(init_branch_prob): Add total_num_conds.
(end_branch_prob): Likewise.
* tree-core.h (struct tree_exp): Add condition_uid.
* tree-profile.cc (struct conds_ctx): New.
(CONDITIONS_MAX_TERMS): New.
(EDGE_CONDITION): New.
(topological_cmp): New.
(index_of): New.
(single_p): New.
(single_edge): New.
(contract_edge_up): New.
(struct outcomes): New.
(conditional_succs): New.
(condition_index): New.
(condition_uid): New.
(masking_vectors): New.
(emit_assign): New.
(emit_bitwise_op): New.
(make_top_index_visit): New.
(make_top_index): New.
(paths_between): New.
(struct condcov): New.
(cov_length): New.
(cov_blocks): New.
(cov_masks): New.
(cov_maps): New.
(cov_free): New.
(find_conditions): New.
(struct counters): New.
(find_counters): New.
(resolve_counter): New.
(resolve_counters): New.
(instrument_decisions): New.
(tree_profiling): Check condition_coverage_flag.
(pass_ipa_tree_profile::gate): Likewise.
* tree.h (SET_EXPR_UID): New.
(EXPR_COND_UID): New.

libgcc/ChangeLog:

* libgcov-merge.c (__gcov_merge_ior): New.

gcc/testsuite/ChangeLog:

* lib/gcov.exp: Add condition coverage test function.
* g++.dg/gcov/gcov-18.C: New test.
* gcc.misc-tests/gcov-19.c: New test.
* gcc.misc-tests/gcov-20.c: New test.
* gcc.misc-tests/gcov-21.c: New test.
* gcc.misc-tests/gcov-22.c: New test.
* gcc.misc-tests/gcov-23.c: New test.
---
   gcc/builtins.cc|2 +-
   gcc/collect2.cc|7 +-
   gcc/common.opt |9 +
   gcc/doc/gcov.texi  |   38 +
   gcc/doc/invoke.texi|   21 +
   gcc/function.cc|1 +
   gcc/function.h |4 +
   gcc/gcc.cc |4 +-
   gcc/gcov-counter.def   |3 +
   gcc/gcov-dump.cc   |   24 +
   gcc/gcov-io.h  |3 +
   gcc/gcov.cc|  209 ++-
   gcc/gimplify.cc|  123 +-
   gcc/ipa-inline.cc  |2 +-
   gcc/ipa-split.cc   |2 +-
   gcc/passes.cc  |3 +-
   gcc/profile

[wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx1036 support

[Tobias Burnus]

I experimented with some variants to make clearer that each of RDNA2 and 
RNDA3 applies to two card types, but at the end I settled on the 
fewest-word version.


Comments, remarks, suggestions? (To this change or in general?)

Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn

Compiler flags, listing the the gfx* cards: 
https://gcc.gnu.org/onlinedocs/gcc/AMD-GCN-Options.html


Tobias

PS: On the compiler side, I am looking forward to a .def file which 
reduces the number of files to change when adding a new gfx* card, given 
that we have doubled the number of entries. [Well, 1 missing but I know 
of one WIP addition.]
gcc-14/changes.html (AMD GCN): Mention gfx1036 support

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 8ac08e9a..b4c602a5 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -623,8 +623,9 @@ a work-in-progress.
 AMD Radeon (GCN)
 
 
-  Initial support for the AMD Radeon gfx1030 (RDNA2),
-gfx1100 and gfx1103 (RDNA3) devices has been
+  Initial support for the AMD Radeon gfx1030,
+gfx1036 (RDNA2), gfx1100 and
+gfx1103 (RDNA3) devices has been
 added. LLVM 15+ (assembler and linker) is https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa";>required
 to support GFX11.

Re: [wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx1036 support

[Andrew Stubbs]

On 15/04/2024 11:03, Tobias Burnus wrote:
I experimented with some variants to make clearer that each of RDNA2 and 
RNDA3 applies to two card types, but at the end I settled on the 
fewest-word version.


Comments, remarks, suggestions? (To this change or in general?)

Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn

Compiler flags, listing the the gfx* cards: 
https://gcc.gnu.org/onlinedocs/gcc/AMD-GCN-Options.html


Tobias

PS: On the compiler side, I am looking forward to a .def file which 
reduces the number of files to change when adding a new gfx* card, given 
that we have doubled the number of entries. [Well, 1 missing but I know 
of one WIP addition.]


LGTM

Andrew

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

[Alex Coplan]

On 04/04/2024 11:00, Alex Coplan wrote:
> Hi,
> 
> This adds a note to the GCC 14 release notes mentioning support for
> __has_{feature,extension} (PR60512).
> 
> OK to commit?

Ping.  Is this changes.html patch OK?  I guess it needs a review from C++
maintainers since it adds to the C++ section.

> 
> Thanks,
> Alex

> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 9fd224c1..facead8d 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -242,6 +242,12 @@ a work-in-progress.
>constinit and optimized dynamic initialization
>  
>
> +  The Clang language extensions __has_feature and
> +__has_extension have been implemented in GCC.  These
> +are available from C, C++, and Objective-C(++).
> +This is primarily intended to aid the portability of code written
> +against Clang.
> +  
>  
>  
>  Runtime Library (libstdc++)

[PATCH] c, v3: Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 10:05:58AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > > struct S;
> > > typedef struct S **V[10];
> > > V **foo (int x) { return 0; }
> > > struct S { int s; };
> > > either.
> > > So, maybe let's drop the ipa-free-lang-data.cc part?
> > > Seems fld_incomplete_type_of uses fld_type_variant which should
> > > copy over TYPE_CANONICAL.
> > 
> > If you have a testcase that still triggers it would be nice to see it.
> 
> I don't, that is why I'm now suggesting to just drop that hunk.

Actually no, I've just screwed up something in my testing.
One can reproduce it easily with -O2 -flto 20021205-1.c -std=c23
if the ipa-free-lang-data.cc hunk is removed.
This happens when fld_incomplete_type_of is called on a POINTER_TYPE
to RECORD_TYPE x, where the RECORD_TYPE x is not the TYPE_MAIN_VARIANT,
but another variant created by set_underlying_type.  The
c_update_type_canonical didn't touch TYPE_CANONICAL in those, I was too
afraid I don't know what TYPE_CANONICAL should be for all variant types,
so that TREE_TYPE (t) had TYPE_CANONICAL NULL.  But when we call
fld_incomplete_type_of on that TREE_TYPE (t), it sees it isn't
TYPE_MAIN_VARIANT, so calls
  return (fld_type_variant
  (fld_incomplete_type_of (TYPE_MAIN_VARIANT (t), fld), t, fld));
but TYPE_MAIN_VARIANT (t) has already TYPE_CANONICAL (TYPE_MAIN_VARIANT (t))
== TYPE_MAIN_VARIANT (t), that one has been completed on finish_struct.
And so we trigger the assertion, because
TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))
is no longer true, the former is non-NULL, the latter is NULL.

But looking at all the build_variant_type_copy callers and the call itself,
the call itself sets TYPE_CANONICAL to the TYPE_CANONICAL of the type on
which it is called and the only caller I can find that changes
TYPE_CANONICAL sometimes is build_qualified_type.
So, I'd hope that normally all variant types of an aggregate type (or
pointer type) have the same TYPE_CANONICAL if they have the same TYPE_QUALS
and if they have it different, they have TYPE_CANONICAL of
build_qualified_type of the base TYPE_CANONICAL.

With the following updated patch (ipa-free-lang-data.cc hunk removed,
c_update_type_canonical function updated, plus removed trailing whitespace
from tests),
make check-gcc RUNTESTFLAGS="--target_board=unix/-std=gnu23 
compile.exp='20021205-1.c 20040214-2.c 20060109-1.c pr113623.c pr46866.c 
pta-1.c' execute.exp='pr33870-1.c pr33870.c'"
no longer ICEs (have just expected FAILs on 20040214-2.c which isn't
compatible with C23) and make check-gcc -j32 doesn't regress compared
to the unpatched one.

Is this ok for trunk if it passes full bootstrap/regtest?

2024-04-15  Martin Uecker  
Jakub Jelinek  

PR lto/114574
PR c/114361
gcc/c/
* c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not
ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY.
(parser_xref_tag): Likewise.
(start_struct): For flag_isoc23 use SET_TYPE_STRUCTURAL_EQUALITY.
(c_update_type_canonical): New function.
(finish_struct): Put NULL as second == operand rather than first.
Assert TYPE_STRUCTURAL_EQUALITY_P.  Call c_update_type_canonical.
* c-typeck.cc (composite_type_internal): Use
SET_TYPE_STRUCTURAL_EQUALITY.  Formatting fix.
gcc/testsuite/
* gcc.dg/pr114574-1.c: New test.
* gcc.dg/pr114574-2.c: New test.
* gcc.dg/pr114361.c: New test.
* gcc.dg/c23-tag-incomplete-1.c: New test.
* gcc.dg/c23-tag-incomplete-2.c: New test.

--- gcc/c/c-decl.cc.jj  2024-04-09 09:29:04.824520299 +0200
+++ gcc/c/c-decl.cc 2024-04-15 12:26:43.000790475 +0200
@@ -5051,6 +5051,8 @@ shadow_tag_warned (const struct c_declsp
  if (t == NULL_TREE)
{
  t = make_node (code);
+ if (flag_isoc23 && code != ENUMERAL_TYPE)
+   SET_TYPE_STRUCTURAL_EQUALITY (t);
  pushtag (input_location, name, t);
}
}
@@ -8809,6 +8811,8 @@ parser_xref_tag (location_t loc, enum tr
  the forward-reference will be altered into a real type.  */
 
   ref = make_node (code);
+  if (flag_isoc23 && code != ENUMERAL_TYPE)
+SET_TYPE_STRUCTURAL_EQUALITY (ref);
   if (code == ENUMERAL_TYPE)
 {
   /* Give the type a default layout like unsigned int
@@ -8910,6 +8914,8 @@ start_struct (location_t loc, enum tree_
   if (ref == NULL_TREE || TREE_CODE (ref) != code)
 {
   ref = make_node (code);
+  if (flag_isoc23)
+   SET_TYPE_STRUCTURAL_EQUALITY (ref);
   pushtag (loc, name, ref);
 }
 
@@ -9347,6 +9353,45 @@ is_flexible_array_member_p (bool is_last
   return false;
 }
 
+/* Recompute TYPE_CANONICAL for variants of the type including qualified
+   versions of the type and related pointer types after an aggregate type
+   has be

Re: [gcc r14-7544] gccrs: libproc_macro: Build statically

[Thomas Schwinge]

Hi!

On 2024-01-16T17:43:10+, Arthur Cohen via Gcc-cvs  
wrote:
> https://gcc.gnu.org/g:71180a9eed367667e7b2c3f6aea1ee1bba15e9b3
>
> commit r14-7544-g71180a9eed367667e7b2c3f6aea1ee1bba15e9b3
> Author: Pierre-Emmanuel Patry 
> Date:   Wed Apr 26 10:31:35 2023 +0200
>
> gccrs: libproc_macro: Build statically
> 
> We do not need dynamic linking, all use case of this library cover can
> be done statically hence the change.
> 
> gcc/rust/ChangeLog:
> 
> * Make-lang.in: Link against the static libproc_macro.

> --- a/gcc/rust/Make-lang.in
> +++ b/gcc/rust/Make-lang.in
> @@ -182,11 +182,14 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
>  
>  rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
>  
> +RUST_LDFLAGS = $(LDFLAGS) -L./../libgrust/libproc_macro
> +RUST_LIBDEPS = $(LIBDEPS) ../libgrust/libproc_macro/libproc_macro.a
> +
>  # The compiler itself is called crab1
> -crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBDEPS) $(rust.prev)
> +crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(RUST_LIBDEPS) 
> $(rust.prev)
>   @$(call LINK_PROGRESS,$(INDEX.rust),start)
> - +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
> -   $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
> + +$(LLINKER) $(ALL_LINKERFLAGS) $(RUST_LDFLAGS) -o $@ \
> +   $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) 
> ../libgrust/libproc_macro/libproc_macro.a $(BACKENDLIBS)
>   @$(call LINK_PROGRESS,$(INDEX.rust),end)

The 'crab1' compiler is (at least potentially) just one of several
executables that 'gcc/rust/Make-lang.in' may build, which may all have
different library dependencies, etc.  Instead of via generic 'RUST_[...]'
variables, those dependencies etc. should therefore be specified as they
are individually necessary.

I've pushed to trunk branch the following clean-up commits, see attached:

  - commit cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 "Remove 
'libgrust/libproc_macro_internal' from 'gcc/rust/Make-lang.in:RUST_LDFLAGS'"
  - commit f7c8fa7280c85cbdea45be9c09f36123ff16a78a "Inline 
'gcc/rust/Make-lang.in:RUST_LDFLAGS' into single user"
  - commit 24d92f65f9ed9b3c730c59f700ce2f5c038c8207 "Add 
'gcc/rust/Make-lang.in:LIBPROC_MACRO_INTERNAL'"
  - commit e3fda76af4f342ad1ba8bd901a72d811e8357e99 "Inline 
'gcc/rust/Make-lang.in:RUST_LIBDEPS' into single user"


Grüße
 Thomas


>From cb70a49b30f0a22ec7a1b7df29c3ab370d603f90 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Feb 2024 22:41:42 +0100
Subject: [PATCH 1/4] Remove 'libgrust/libproc_macro_internal' from
 'gcc/rust/Make-lang.in:RUST_LDFLAGS'

This isn't necessary, as the full path to 'libproc_macro_internal.a' is
specified elsewhere.

	gcc/rust/
	* Make-lang.in (RUST_LDFLAGS): Remove
	'libgrust/libproc_macro_internal'.
---
 gcc/rust/Make-lang.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index 4d73412739d..e901668b93d 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -208,7 +208,7 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
 
 rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
 
-RUST_LDFLAGS = $(LDFLAGS) -L./../libgrust/libproc_macro_internal
+RUST_LDFLAGS = $(LDFLAGS)
 RUST_LIBDEPS = $(LIBDEPS) ../libgrust/libproc_macro_internal/libproc_macro_internal.a
 
 # The compiler itself is called crab1
-- 
2.34.1

>From f7c8fa7280c85cbdea45be9c09f36123ff16a78a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Feb 2024 22:45:18 +0100
Subject: [PATCH 2/4] Inline 'gcc/rust/Make-lang.in:RUST_LDFLAGS' into single
 user

	gcc/rust/
	* Make-lang.in (RUST_LDFLAGS): Inline into single user.
---
 gcc/rust/Make-lang.in | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index e901668b93d..ffeb325d6ce 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -208,13 +208,12 @@ RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
 
 rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
 
-RUST_LDFLAGS = $(LDFLAGS)
 RUST_LIBDEPS = $(LIBDEPS) ../libgrust/libproc_macro_internal/libproc_macro_internal.a
 
 # The compiler itself is called crab1
 crab1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(RUST_LIBDEPS) $(rust.prev)
 	@$(call LINK_PROGRESS,$(INDEX.rust),start)
-	+$(LLINKER) $(ALL_LINKERFLAGS) $(RUST_LDFLAGS) -o $@ \
+	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 	  $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) ../libgrust/libproc_macro_internal/libproc_macro_internal.a $(BACKENDLIBS)
 	@$(call LINK_PROGRESS,$(INDEX.rust),end)
 
-- 
2.34.1

>From 24d92f65f9ed9b3c730c59f700ce2f5c038c8207 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 28 Feb 2024 22:51:24 +0100
Subject: [PATCH 3/4] Add 'gcc/rust/Make-lang.in:LIBPROC_MACRO_INTERNAL'

... to avoid verbatim repetition.

	gcc/rust/
	* Make-lang.in (LIBPROC_MACRO_INTERNAL): New.
	(RUST_LIBDEPS, crab1$(exeext)): Use it.
---
 gcc/rust/Make-lang.in | 6 --
 1 file c

Re: [PATCH] build: Check for cargo when building rust language

[Thomas Schwinge]

Hi!

On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
> The rust frontend requires cargo to build some of it's components,

In GCC upstream still: 's%requires%is going to require'.  ;-)

> it's presence was not checked during configuration.

After confirming the desired semantics/diagnostics, I've now pushed this
to trunk branch in commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language".


I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.


Grüße
 Thomas


> Prevent rust language from building when cargo is
> missing.
>
> config/ChangeLog:
>
>   * acx.m4: Add a macro to check for rust
>   components.
>
> ChangeLog:
>
>   * configure: Regenerate.
>   * configure.ac: Emit an error message when cargo
>   is missing.
>
> Signed-off-by: Pierre-Emmanuel Patry 
> ---
>  config/acx.m4 |  11 +
>  configure | 117 ++
>  configure.ac  |  18 
>  3 files changed, 146 insertions(+)
>
> diff --git a/config/acx.m4 b/config/acx.m4
> index 7efe98aaf96..3c5fe67342e 100644
> --- a/config/acx.m4
> +++ b/config/acx.m4
> @@ -424,6 +424,17 @@ else
>  fi
>  ])
>  
> +# Test for Rust
> +# We require cargo and rustc for some parts of the rust compiler.
> +AC_DEFUN([ACX_PROG_CARGO],
> +[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
> +AC_CHECK_TOOL(CARGO, cargo, no)
> +if test "x$CARGO" != xno; then
> +  have_cargo=yes
> +else
> +  have_cargo=no
> +fi])
> +
>  # Test for D.
>  AC_DEFUN([ACX_PROG_GDC],
>  [AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
> diff --git a/configure b/configure
> index 874966fb9f0..46e66e20197 100755
> --- a/configure
> +++ b/configure
> @@ -714,6 +714,7 @@ PGO_BUILD_GEN_CFLAGS
>  HAVE_CXX11_FOR_BUILD
>  HAVE_CXX11
>  do_compare
> +CARGO
>  GDC
>  GNATMAKE
>  GNATBIND
> @@ -5786,6 +5787,104 @@ else
>have_gdc=no
>  fi
>  
> +
> +if test -n "$ac_tool_prefix"; then
> +  # Extract the first word of "${ac_tool_prefix}cargo", so it can be a 
> program name with args.
> +set dummy ${ac_tool_prefix}cargo; ac_word=$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_prog_CARGO+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  if test -n "$CARGO"; then
> +  ac_cv_prog_CARGO="$CARGO" # Let the user override the test.
> +else
> +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> +  IFS=$as_save_IFS
> +  test -z "$as_dir" && as_dir=.
> +for ac_exec_ext in '' $ac_executable_extensions; do
> +  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> +ac_cv_prog_CARGO="${ac_tool_prefix}cargo"
> +$as_echo "$as_me:${as_lineno-$LINENO}: found 
> $as_dir/$ac_word$ac_exec_ext" >&5
> +break 2
> +  fi
> +done
> +  done
> +IFS=$as_save_IFS
> +
> +fi
> +fi
> +CARGO=$ac_cv_prog_CARGO
> +if test -n "$CARGO"; then
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CARGO" >&5
> +$as_echo "$CARGO" >&6; }
> +else
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +
> +fi
> +if test -z "$ac_cv_prog_CARGO"; then
> +  ac_ct_CARGO=$CARGO
> +  # Extract the first word of "cargo", so it can be a program name with args.
> +set dummy cargo; ac_word=$2
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
> +$as_echo_n "checking for $ac_word... " >&6; }
> +if ${ac_cv_prog_ac_ct_CARGO+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  if test -n "$ac_ct_CARGO"; then
> +  ac_cv_prog_ac_ct_CARGO="$ac_ct_CARGO" # Let the user override the test.
> +else
> +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
> +for as_dir in $PATH
> +do
> +  IFS=$as_save_IFS
> +  test -z "$as_dir" && as_dir=.
> +for ac_exec_ext in '' $ac_executable_extensions; do
> +  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
> +ac_cv_prog_ac_ct_CARGO="cargo"
> +$as_echo "$as_me:${as_lineno-$LINENO}: found 
> $as_dir/$ac_word$ac_exec_ext" >&5
> +break 2
> +  fi
> +done
> +  done
> +IFS=$as_save_IFS
> +
> +fi
> +fi
> +ac_ct_CARGO=$ac_cv_prog_ac_ct_CARGO
> +if test -n "$ac_ct_CARGO"; then
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CARGO" >&5
> +$as_echo "$ac_ct_CARGO" >&6; }
> +else
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
> +$as_echo "no" >&6; }
> +fi
> +
> +  if test "x$ac_ct_CARGO" = x; then
> +CARGO="no"
> +  else
> +case $cross_compiling:$ac_tool_warned in
> +yes:)
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not 
> prefixed with host triplet" >&5
> +$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" 
> >&2;}
> +ac_tool_warned=yes ;;
> +esac
> +CARGO=$ac_ct_CARGO
> +  fi
> +else
> +  CARGO="$ac_cv_prog_CARGO"
> +fi
> +
> +if test "x$CARGO" != xno; then
> +  have_cargo=yes
> +els

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

[Rainer Orth]

Hi Jørgen,

>> the new gcc.misc-tests/gcov-22.c test loops on SPARC (both Solaris and
>> Linux).  I've filed PR gcov-profile/114720 for this, but couldn't find
>> any bugzilla account of yours to Cc:
>>  Rainer
>> 
>
> Rainer,
>
> Could you please try this patch? I don't have a sparc nor non-glibc build
> (and getting a virtual one up will take a while). I suppose the problem is

given that the test also FAILs on Linux/sparc64, it's not a
glibc-vs-non-glibc issue.

FWIW, there are both Solaris/SPARC and Linux/sparc64 systems available
in the cfarm; no need to build one yourself.  But fully agreed, running
a full bootstrap to verify a single testcase is a bit much if it can be
done more easily ;-)

> that after longjmp the return address is to the call to setdest(), not
> jump() (like is assumed), which creates the loop. If so, just guarding the
> longjmp should be fine, the point of the test is to make sure that both
> branches can be taken and recorded when the cond is a setjmp. If it works I
> will document it and post the patch.

I've just tried the patch on both sparc-sun-solaris2.11 and
i386-pc-solaris2.11 and the test now PASSes on both.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH] gcov-profile/114715 - missing coverage for switch

[Richard Biener]

The following avoids missing coverage for the line of a switch statement
which happens when gimplification emits a BIND_EXPR wrapping the switch
as that prevents us from setting locations on the containing statements
via annotate_all_with_location.  Instead set the location of the GIMPLE
switch directly.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?

Thanks,
Richard.

PR gcov-profile/114715
* gimplify.cc (gimplify_switch_expr): Set the location of the
GIMPLE switch.

* gcc.misc-tests/gcov-24.c: New testcase.
---
 gcc/gimplify.cc|  1 +
 gcc/testsuite/gcc.misc-tests/gcov-24.c | 30 ++
 2 files changed, 31 insertions(+)
 create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-24.c

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 3df58b962f3..26e96ada4c7 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3017,6 +3017,7 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pre_p)
 
   switch_stmt = gimple_build_switch (SWITCH_COND (switch_expr),
 default_case, labels);
+  gimple_set_location (switch_stmt, EXPR_LOCATION (switch_expr));
   /* For the benefit of -Wimplicit-fallthrough, if switch_body_seq
 ends with a GIMPLE_LABEL holding SWITCH_BREAK_LABEL_P LABEL_DECL,
 wrap the GIMPLE_SWITCH up to that GIMPLE_LABEL into a GIMPLE_BIND,
diff --git a/gcc/testsuite/gcc.misc-tests/gcov-24.c 
b/gcc/testsuite/gcc.misc-tests/gcov-24.c
new file mode 100644
index 000..395099bd7ae
--- /dev/null
+++ b/gcc/testsuite/gcc.misc-tests/gcov-24.c
@@ -0,0 +1,30 @@
+/* { dg-options "-fprofile-arcs -ftest-coverage" } */
+/* { dg-do run { target native } } */
+
+int main()
+{
+  int a = 1;
+  int b = 2;
+  int c = -3;
+  switch(a) /* count(1) */
+{
+case 1: /* count(1) */
+c = 3;
+switch(b) { /* count(1) */
+  case 1: /* count(#) */
+  c = 4;
+  break;
+  case 2: /* count(1) */
+  c = 5;
+  break;
+}
+break;
+case 2: /* count(#) */
+c = 6;
+break;
+default: /* count(#) */
+break;
+}
+}
+
+/* { dg-final { run-gcov gcov-24.c } } */
-- 
2.35.3

Re: [PATCH] gcov-profile/114715 - missing coverage for switch

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 01:28:00PM +0200, Richard Biener wrote:
> The following avoids missing coverage for the line of a switch statement
> which happens when gimplification emits a BIND_EXPR wrapping the switch
> as that prevents us from setting locations on the containing statements
> via annotate_all_with_location.  Instead set the location of the GIMPLE
> switch directly.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?
> 
> Thanks,
> Richard.
> 
>   PR gcov-profile/114715
>   * gimplify.cc (gimplify_switch_expr): Set the location of the
>   GIMPLE switch.
> 
>   * gcc.misc-tests/gcov-24.c: New testcase.

LGTM, thanks.

Jakub

Re: [PATCH] c, v3: Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

[Richard Biener]

On Mon, 15 Apr 2024, Jakub Jelinek wrote:

> On Mon, Apr 15, 2024 at 10:05:58AM +0200, Jakub Jelinek wrote:
> > On Mon, Apr 15, 2024 at 10:02:25AM +0200, Richard Biener wrote:
> > > > Though, haven't managed to reproduce it with -O2 -flto -std=c23
> > > > struct S;
> > > > typedef struct S **V[10];
> > > > V **foo (int x) { return 0; }
> > > > struct S { int s; };
> > > > either.
> > > > So, maybe let's drop the ipa-free-lang-data.cc part?
> > > > Seems fld_incomplete_type_of uses fld_type_variant which should
> > > > copy over TYPE_CANONICAL.
> > > 
> > > If you have a testcase that still triggers it would be nice to see it.
> > 
> > I don't, that is why I'm now suggesting to just drop that hunk.
> 
> Actually no, I've just screwed up something in my testing.
> One can reproduce it easily with -O2 -flto 20021205-1.c -std=c23
> if the ipa-free-lang-data.cc hunk is removed.
> This happens when fld_incomplete_type_of is called on a POINTER_TYPE
> to RECORD_TYPE x, where the RECORD_TYPE x is not the TYPE_MAIN_VARIANT,
> but another variant created by set_underlying_type.  The
> c_update_type_canonical didn't touch TYPE_CANONICAL in those, I was too
> afraid I don't know what TYPE_CANONICAL should be for all variant types,
> so that TREE_TYPE (t) had TYPE_CANONICAL NULL.  But when we call
> fld_incomplete_type_of on that TREE_TYPE (t), it sees it isn't
> TYPE_MAIN_VARIANT, so calls
>   return (fld_type_variant
>   (fld_incomplete_type_of (TYPE_MAIN_VARIANT (t), fld), t, fld));
> but TYPE_MAIN_VARIANT (t) has already TYPE_CANONICAL (TYPE_MAIN_VARIANT (t))
> == TYPE_MAIN_VARIANT (t), that one has been completed on finish_struct.
> And so we trigger the assertion, because
> TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))
> is no longer true, the former is non-NULL, the latter is NULL.
> 
> But looking at all the build_variant_type_copy callers and the call itself,
> the call itself sets TYPE_CANONICAL to the TYPE_CANONICAL of the type on
> which it is called and the only caller I can find that changes
> TYPE_CANONICAL sometimes is build_qualified_type.
> So, I'd hope that normally all variant types of an aggregate type (or
> pointer type) have the same TYPE_CANONICAL if they have the same TYPE_QUALS
> and if they have it different, they have TYPE_CANONICAL of
> build_qualified_type of the base TYPE_CANONICAL.

The middle-end assumes that TYPE_CANONICAL of all variant types are
the same, for TBAA purposes it immediately "puns" to
TYPE_CANONICAL (TYPE_MAIN_VARIANT (..)).  It also assumes that
the canonical type is not a variant type.  Note we never "honor"
TYPE_STRUCTURAL_EQUALITY_P on a variant type (because we don't look
at it, we only look at whether the main variant has
TYPE_STRUCTURAL_EQUALITY_P).

Thus, TYPE_CANONICAL of variant types in principle doesn't need to be
set (but not all places might go the extra step looking at the main
variant before accessing TYPE_CANONICAL).

Richard.

> With the following updated patch (ipa-free-lang-data.cc hunk removed,
> c_update_type_canonical function updated, plus removed trailing whitespace
> from tests),
> make check-gcc RUNTESTFLAGS="--target_board=unix/-std=gnu23 
> compile.exp='20021205-1.c 20040214-2.c 20060109-1.c pr113623.c pr46866.c 
> pta-1.c' execute.exp='pr33870-1.c pr33870.c'"
> no longer ICEs (have just expected FAILs on 20040214-2.c which isn't
> compatible with C23) and make check-gcc -j32 doesn't regress compared
> to the unpatched one.
> 
> Is this ok for trunk if it passes full bootstrap/regtest?
> 
> 2024-04-15  Martin Uecker  
>   Jakub Jelinek  
> 
>   PR lto/114574
>   PR c/114361
> gcc/c/
>   * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not
>   ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY.
>   (parser_xref_tag): Likewise.
>   (start_struct): For flag_isoc23 use SET_TYPE_STRUCTURAL_EQUALITY.
>   (c_update_type_canonical): New function.
>   (finish_struct): Put NULL as second == operand rather than first.
>   Assert TYPE_STRUCTURAL_EQUALITY_P.  Call c_update_type_canonical.
>   * c-typeck.cc (composite_type_internal): Use
>   SET_TYPE_STRUCTURAL_EQUALITY.  Formatting fix.
> gcc/testsuite/
>   * gcc.dg/pr114574-1.c: New test.
>   * gcc.dg/pr114574-2.c: New test.
>   * gcc.dg/pr114361.c: New test.
>   * gcc.dg/c23-tag-incomplete-1.c: New test.
>   * gcc.dg/c23-tag-incomplete-2.c: New test.
> 
> --- gcc/c/c-decl.cc.jj2024-04-09 09:29:04.824520299 +0200
> +++ gcc/c/c-decl.cc   2024-04-15 12:26:43.000790475 +0200
> @@ -5051,6 +5051,8 @@ shadow_tag_warned (const struct c_declsp
> if (t == NULL_TREE)
>   {
> t = make_node (code);
> +   if (flag_isoc23 && code != ENUMERAL_TYPE)
> + SET_TYPE_STRUCTURAL_EQUALITY (t);
> pushtag (input_location, name, t);
>   }
>   }
> @@ -8809,6 +8811,8 @@ parser_xref_tag (location_t loc, enum tr
>   the forward-

Re: [PATCH v10 1/2] Add condition coverage (MC/DC)

[Jørgen Kvalsvik]

On 15/04/2024 13:18, Rainer Orth wrote:

Hi Jørgen,


the new gcc.misc-tests/gcov-22.c test loops on SPARC (both Solaris and
Linux).  I've filed PR gcov-profile/114720 for this, but couldn't find
any bugzilla account of yours to Cc:
Rainer



Rainer,

Could you please try this patch? I don't have a sparc nor non-glibc build
(and getting a virtual one up will take a while). I suppose the problem is


given that the test also FAILs on Linux/sparc64, it's not a
glibc-vs-non-glibc issue.


Sure, I just figured that a different libc setjmp might have the same 
behaviour also on x86.




FWIW, there are both Solaris/SPARC and Linux/sparc64 systems available
in the cfarm; no need to build one yourself.  But fully agreed, running
a full bootstrap to verify a single testcase is a bit much if it can be
done more easily ;-)


I was not aware of the cfarm, that seems like a splendid resource, I'll 
create an account.





that after longjmp the return address is to the call to setdest(), not
jump() (like is assumed), which creates the loop. If so, just guarding the
longjmp should be fine, the point of the test is to make sure that both
branches can be taken and recorded when the cond is a setjmp. If it works I
will document it and post the patch.


I've just tried the patch on both sparc-sun-solaris2.11 and
i386-pc-solaris2.11 and the test now PASSes on both.

Thanks.
 Rainer



Ok, thanks, I'll type up a patch and submit again for review.

build: Don't check for host-prefixed 'cargo' program (was: [PATCH] build: Check for cargo when building rust language)

[Thomas Schwinge]

Hi!

On 2024-04-15T13:14:42+0200, I wrote:
> On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
>> The rust frontend requires cargo to build some of it's components,
>
> In GCC upstream still: 's%requires%is going to require'.  ;-)
>
>> it's presence was not checked during configuration.
>
> After confirming the desired semantics/diagnostics, I've now pushed this
> to trunk branch in commit 3e1e73fc99584440e5967577f2049573eeaf4596
> "build: Check for cargo when building rust language".
>
>
> I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
> 'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
> 'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.

OK to push "build: Don't check for host-prefixed 'cargo' program", see
attached?


Grüße
 Thomas


>From 913be0412665d02561f8aeb999860ce8d292c61e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 15 Apr 2024 13:33:48 +0200
Subject: [PATCH] build: Don't check for host-prefixed 'cargo' program

Follow-up to commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language":

On 2024-04-15T13:14:42+0200, I wrote:
> I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
> 'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
> 'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.

	* configure: Regenerate.
	config/
	* acx.m4 (ACX_PROG_CARGO): Use 'AC_CHECK_PROGS'.
---
 config/acx.m4 |  3 +--
 configure | 64 ++-
 2 files changed, 8 insertions(+), 59 deletions(-)

diff --git a/config/acx.m4 b/config/acx.m4
index 3c5fe67342e..c45e55e7f51 100644
--- a/config/acx.m4
+++ b/config/acx.m4
@@ -427,8 +427,7 @@ fi
 # Test for Rust
 # We require cargo and rustc for some parts of the rust compiler.
 AC_DEFUN([ACX_PROG_CARGO],
-[AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
-AC_CHECK_TOOL(CARGO, cargo, no)
+[AC_CHECK_PROGS(CARGO, cargo, no)
 if test "x$CARGO" != xno; then
   have_cargo=yes
 else
diff --git a/configure b/configure
index dd96445ac4a..e254aa132b5 100755
--- a/configure
+++ b/configure
@@ -5818,10 +5818,10 @@ else
   have_gdc=no
 fi
 
-
-if test -n "$ac_tool_prefix"; then
-  # Extract the first word of "${ac_tool_prefix}cargo", so it can be a program name with args.
-set dummy ${ac_tool_prefix}cargo; ac_word=$2
+for ac_prog in cargo
+do
+  # Extract the first word of "$ac_prog", so it can be a program name with args.
+set dummy $ac_prog; ac_word=$2
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
 $as_echo_n "checking for $ac_word... " >&6; }
 if ${ac_cv_prog_CARGO+:} false; then :
@@ -5837,7 +5837,7 @@ do
   test -z "$as_dir" && as_dir=.
 for ac_exec_ext in '' $ac_executable_extensions; do
   if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
-ac_cv_prog_CARGO="${ac_tool_prefix}cargo"
+ac_cv_prog_CARGO="$ac_prog"
 $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
 break 2
   fi
@@ -5857,59 +5857,9 @@ $as_echo "no" >&6; }
 fi
 
 
-fi
-if test -z "$ac_cv_prog_CARGO"; then
-  ac_ct_CARGO=$CARGO
-  # Extract the first word of "cargo", so it can be a program name with args.
-set dummy cargo; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_ac_ct_CARGO+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  if test -n "$ac_ct_CARGO"; then
-  ac_cv_prog_ac_ct_CARGO="$ac_ct_CARGO" # Let the user override the test.
-else
-as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-for ac_exec_ext in '' $ac_executable_extensions; do
-  if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
-ac_cv_prog_ac_ct_CARGO="cargo"
-$as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
-break 2
-  fi
+  test -n "$CARGO" && break
 done
-  done
-IFS=$as_save_IFS
-
-fi
-fi
-ac_ct_CARGO=$ac_cv_prog_ac_ct_CARGO
-if test -n "$ac_ct_CARGO"; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CARGO" >&5
-$as_echo "$ac_ct_CARGO" >&6; }
-else
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-  if test "x$ac_ct_CARGO" = x; then
-CARGO="no"
-  else
-case $cross_compiling:$ac_tool_warned in
-yes:)
-{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
-$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
-ac_tool_warned=yes ;;
-esac
-CARGO=$ac_ct_CARGO
-  fi
-else
-  CARGO="$ac_cv_prog_CARGO"
-fi
+test -n "$CARGO" || CARGO="no"
 
 if test "x$CARGO" != xno; then
   have_cargo=yes
-- 
2.34.1

Re: [wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx1036 support

[Richard Biener]

On Mon, Apr 15, 2024 at 12:04 PM Tobias Burnus  wrote:
>
> I experimented with some variants to make clearer that each of RDNA2 and
> RNDA3 applies to two card types, but at the end I settled on the
> fewest-word version.
>
> Comments, remarks, suggestions? (To this change or in general?)
>
> Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn
>
> Compiler flags, listing the the gfx* cards:
> https://gcc.gnu.org/onlinedocs/gcc/AMD-GCN-Options.html
>
> Tobias
>
> PS: On the compiler side, I am looking forward to a .def file which
> reduces the number of files to change when adding a new gfx* card, given
> that we have doubled the number of entries. [Well, 1 missing but I know
> of one WIP addition.]

I do wonder whether hot-patching the ELF header from the libgomp plugin
with the actual micro-subarch would be possible to make the driver happy.
We do query the device ISA when initializing the device so we should
be able to massage the ELF header of the object in GOMP_OFFLOAD_load_image
at least within some constraints (ideally we'd mark the ELF object as to
be matched with a device in some group).

Richard.

Re: build: Don't check for host-prefixed 'cargo' program

[Pierre-Emmanuel Patry]

Hi,

On 4/15/24 1:50 PM, Thomas Schwinge wrote:

I now wonder: instead of 'AC_CHECK_TOOL', shouldn't this use
'AC_CHECK_PROG'?  (We always want plain 'cargo', not host-prefixed
'aarch64-linux-gnu-cargo' etc., right?)  I'll look into changing this.


This is a mistake, we should use 'AC_CHECK_PROG'.


OK to push "build: Don't check for host-prefixed 'cargo' program", see
attached?


Yes, attached patch looks good, thank you!

Regards,

--
Patry Pierre-Emmanuel
Compiler Engineer - Embecosm

Re: [PATCH] c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284]

[Jakub Jelinek]

On Fri, Apr 12, 2024 at 03:05:26PM -0400, Jason Merrill wrote:
> > --- gcc/cp/constexpr.cc.jj  2024-02-13 10:29:57.979155641 +0100
> > +++ gcc/cp/constexpr.cc 2024-03-07 19:35:01.032412221 +0100
> > @@ -1877,13 +1877,21 @@ cxx_bind_parameters_in_call (const const
> >   x = build_address (x);
> > }
> > if (TREE_ADDRESSABLE (type))
> > -   /* Undo convert_for_arg_passing work here.  */
> > -   x = convert_from_reference (x);
> > -  /* Normally we would strip a TARGET_EXPR in an initialization context
> > -such as this, but here we do the elision differently: we keep the
> > -TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> > -  arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> > - non_constant_p, overflow_p);
> > +   {
> > + /* Undo convert_for_arg_passing work here.  */
> > + if (TYPE_REF_P (TREE_TYPE (x))
> > + && !same_type_p (type, TREE_TYPE (TREE_TYPE (x
> > +   x = cp_fold_convert (build_reference_type (type), x);
> > + x = convert_from_reference (x);
> > + arg = cxx_eval_constant_expression (ctx, x, vc_glvalue,
> > + non_constant_p, overflow_p);
> > +   }
> > +  else
> > +   /* Normally we would strip a TARGET_EXPR in an initialization context
> > +  such as this, but here we do the elision differently: we keep the
> > +  TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
> > +   arg = cxx_eval_constant_expression (ctx, x, vc_prvalue,
> > +   non_constant_p, overflow_p);
> 
> It seems simpler to move the convert_for_reference after the
> cxx_eval_constant_expression rather than duplicate the call to
> cxx_eval_constant_expression.

They weren't the same, one was trying to evaluate the convert_from_reference
with vc_glvalue, the other evaluates it without that and with vc_prvalue.
Now, I guess the
+ /* Undo convert_for_arg_passing work here.  */
+ if (TYPE_REF_P (TREE_TYPE (x))
+ && !same_type_p (type, TREE_TYPE (TREE_TYPE (x
+   x = cp_fold_convert (build_reference_type (type), x);
part could be thrown away, given the other !same_type_p check (that one is
needed because adjust_temp_type can't deal with that), at least
when I remove that
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26 make check-g++ 
RUNTESTFLAGS="dg.exp='constexpr-dtor* pr114426.C constexpr-111284.C 
constexpr-lifetime7.C'"
still passes.  But if I try to remove even more, like in the patch below,
then I see
FAIL: g++.dg/cpp2a/constexpr-dtor5.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor5.C  -std=c++23 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor5.C  -std=c++26 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++20  (test for errors, line 6)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++20 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++23  (test for errors, line 6)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++23 (test for excess errors)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++26  (test for errors, line 6)
FAIL: g++.dg/cpp2a/constexpr-dtor7.C  -std=c++26 (test for excess errors)
regressions.
E.g.
.../g++.dg/cpp2a/constexpr-dtor5.C:30:20: error: non-constant condition for 
static assertion
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '' 
from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:31:20: error: non-constant condition for 
static assertion
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '' 
from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:32:20: error: non-constant condition for 
static assertion
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '' 
from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '' 
from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '' 
from outside current evaluation is not a constant expression
.../g++.dg/cpp2a/constexpr-dtor5.C:13:7: error: modification of '' 
from outside current evaluation is not a constant expression

--- gcc/cp/constexpr.cc.jj  2024-02-13 10:29:57.979155641 +0100
+++ gcc/cp/constexpr.cc 2024-03-07 19:35:01.032412221 +0100
@@ -1871,9 +1871,6 @@ cxx_bind_parameters_in_call (const const
  x = ctx->object;
  x = build_address (x);
}
-  if (TREE_ADDRESSABLE (type))
-   /* Undo convert_for_arg_passing work here.  */
-   x = convert_from_reference (x);
   /* Normally we would strip a TARGET_EXPR in an initialization context
 such as this, but here we do the elision differently: we keep the
 TARGET_EXPR, and use its CONSTRUCTOR as the value of the parm.  */
@@ -1904,7 +1901,13 @@ cxx_bind_parameters_in_call (const co

Re: [wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx1036 support

[Andrew Stubbs]

On 15/04/2024 13:00, Richard Biener wrote:

On Mon, Apr 15, 2024 at 12:04 PM Tobias Burnus  wrote:


I experimented with some variants to make clearer that each of RDNA2 and
RNDA3 applies to two card types, but at the end I settled on the
fewest-word version.

Comments, remarks, suggestions? (To this change or in general?)

Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn

Compiler flags, listing the the gfx* cards:
https://gcc.gnu.org/onlinedocs/gcc/AMD-GCN-Options.html

Tobias

PS: On the compiler side, I am looking forward to a .def file which
reduces the number of files to change when adding a new gfx* card, given
that we have doubled the number of entries. [Well, 1 missing but I know
of one WIP addition.]


I do wonder whether hot-patching the ELF header from the libgomp plugin
with the actual micro-subarch would be possible to make the driver happy.
We do query the device ISA when initializing the device so we should
be able to massage the ELF header of the object in GOMP_OFFLOAD_load_image
at least within some constraints (ideally we'd mark the ELF object as to
be matched with a device in some group).


This might work in some limited cases, especially if you limit the 
codegen to some subset of the ISA, but in general the metadata on the 
kernel entry-points is device-specific. For example, the gfx908 and 
gfx90a have different granularity on the VGPR count settings. It would 
probably be possible to generate some matching sets.


However, there's probably no need to do that ourselves because the LLVM 
tools now have new generic ELF flags "gfx9-generic", "gfx10-1-generic", 
"gfx10-3-generic", and "gfx11-generic" which supposedly do what you 
want.  I've not experimented with them. I don't know if libraries can 
have the generic variant and still link with the specific variant (the 
only libraries with kernel entry-points are the libgcc init_array and 
fini_array). If not it becomes yet another multilib.


I'm very sure there's no one binary that will run anywhere for real 
usecases.


Andrew

[PATCH] Guard longjmp in test to not inf loop [PR114720]

[Jørgen Kvalsvik]

Guard the longjmp to not infinitely loop. The longjmp (jump) function is
called unconditionally to make test flow simpler, but the jump
destination would return to a point in main that would call longjmp
again. The longjmp is really there to exercise the then-branch of
setjmp, to verify coverage is accurately counted in the presence of
complex edges.

PR gcov-profile/114720

gcc/testsuite/ChangeLog:

* gcc.misc-tests/gcov-22.c: Guard longjmp to not loop.
---
 gcc/testsuite/gcc.misc-tests/gcov-22.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.misc-tests/gcov-22.c 
b/gcc/testsuite/gcc.misc-tests/gcov-22.c
index 641791a7223..7ca78467ca3 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov-22.c
+++ b/gcc/testsuite/gcc.misc-tests/gcov-22.c
@@ -87,7 +87,19 @@ setdest ()
 void
 jump ()
 {
-longjmp (dest, 1);
+/* Protect the longjmp so it will only be done once.  The whole purpose of
+   this function is to help test conditions and instrumentation around
+   setjmp and its complex edges, as both branches should count towards
+   coverage, even when one is taken through longjmp.  If the jump is not
+   guarded it can cause an infinite loop as setdest returns to a point in
+   main before jump (), leading to an infinite loop.  See PR
+   gcov-profile/114720.  */
+static int called_once = 0;
+if (!called_once) /* conditions(suppress) */
+{
+   called_once = 1;
+   longjmp (dest, 1);
+}
 }
 
 int
-- 
2.30.2

[PATCH] gotools: Workaround non-reproduceability of automake

[Jakub Jelinek]

Hi!

The regen bot recently flagged a difference in gotools/Makefile.in.
Trying it locally, it seems pretty random
for i in `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH 
automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo; for i in `seq 
20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH setarch x86_64 -R 
automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo;
14 14 14 0 0 0 14 0 14 0 14 14 14 14 0 14 14 0 0 0 
14 0 14 0 0 14 14 14 0 14 14 0 0 14 14 14 0 0 0 14 
The 14 line git diff is
diff --git a/gotools/Makefile.in b/gotools/Makefile.in
index 36c2ec2abd3..f40883c39be 100644
--- a/gotools/Makefile.in
+++ b/gotools/Makefile.in
@@ -704,8 +704,8 @@ distclean-generic:
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-@NATIVE_FALSE@install-exec-local:
 @NATIVE_FALSE@uninstall-local:
+@NATIVE_FALSE@install-exec-local:
 clean: clean-am
 
 clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
so whether it is
@NATIVE_FALSE@install-exec-local:
@NATIVE_FALSE@uninstall-local:
or
@NATIVE_FALSE@uninstall-local:
@NATIVE_FALSE@install-exec-local:
depends on some hash table traversal or what.

I'm not familiar with automake/m4 enough to debug that, so I'm
instead offering a workaround, with this patch the order is deterministic.

2024-04-15  Jakub Jelinek  

* Makefile.am (install-exec-local, uninstall-local): Add goals
on the else branch of if NATIVE to ensure reproducibility.
* Makefile.in: Regenerate.

--- gotools/Makefile.am.jj  2023-11-04 09:02:35.802995614 +0100
+++ gotools/Makefile.am 2024-04-15 14:30:03.647171636 +0200
@@ -366,5 +366,7 @@ else
 # only do this if such a compiler is available.  We also need to get
 # the right values for GOARCH and GOOS in the default build context in
 # the go/build package.  Figure this out later.
+install-exec-local:
+uninstall-local:
 
 endif
--- gotools/Makefile.in.jj  2023-11-03 17:08:46.000439645 +0100
+++ gotools/Makefile.in 2024-04-15 14:31:32.270040117 +0200
@@ -704,8 +704,6 @@ distclean-generic:
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
-@NATIVE_FALSE@install-exec-local:
-@NATIVE_FALSE@uninstall-local:
 clean: clean-am
 
 clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
@@ -1035,6 +1033,8 @@ mostlyclean-local:
 # only do this if such a compiler is available.  We also need to get
 # the right values for GOARCH and GOOS in the default build context in
 # the go/build package.  Figure this out later.
+@NATIVE_FALSE@install-exec-local:
+@NATIVE_FALSE@uninstall-local:
 
 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

Jakub

[PATCH] RISC-V: Add VLS to mask vec_extract [PR114668].

[Robin Dapp]

Hi,

this adds the missing VLS modes to the mask extract expanders.
I found a dump scan difficult to create reliably so I just
kept the PR's run test case.

Regtested on rv64gcv. 

Regards
 Robin

gcc/ChangeLog:

PR target/114668

* config/riscv/autovec.md: Add VLS.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr114668.c: New test.
---
 gcc/config/riscv/autovec.md   |  4 +--
 .../gcc.target/riscv/rvv/autovec/pr114668.c   | 35 +++
 2 files changed, 37 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114668.c

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 3b32369f68c..aa1ae0fe075 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -1427,7 +1427,7 @@ (define_expand "vec_extract"
 (define_expand "vec_extractqi"
   [(set (match_operand:QI0 "register_operand")
  (vec_select:QI
-   (match_operand:VB 1 "register_operand")
+   (match_operand:VB_VLS 1 "register_operand")
(parallel
 [(match_operand  2 "nonmemory_operand")])))]
   "TARGET_VECTOR"
@@ -1453,7 +1453,7 @@ (define_expand "vec_extractqi"
 (define_expand "vec_extractbi"
   [(set (match_operand:QI0 "register_operand")
  (vec_select:QI
-   (match_operand:VB 1 "register_operand")
+   (match_operand:VB_VLS 1 "register_operand")
(parallel
 [(match_operand  2 "nonmemory_operand")])))]
   "TARGET_VECTOR"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114668.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114668.c
new file mode 100644
index 000..3a13c3c0012
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr114668.c
@@ -0,0 +1,35 @@
+/* { dg-do run } */
+/* { dg-require-effective-target riscv_v } */
+/* { dg-options { -O3 -fno-vect-cost-model -march=rv64gcv -mabi=lp64d  } } */
+
+char a;
+int b;
+short e[14];
+char f[4][12544];
+_Bool c[4][5];
+
+__attribute__ ((noipa))
+void foo (int a)
+{
+  if (a != 1)
+__builtin_abort ();
+}
+
+int main ()
+{
+  for (int i = 0; i < 4; ++i)
+for (int l = 0; l < 15; ++l)
+  for (int m = 0; m < 15; ++m)
+   f[i][l * m] = 3;
+  for (int j = 0; j < 4; j += 1)
+for (int k = 3; k < 13; k += 3)
+  for (_Bool l = 0; l < 1; l = 1)
+   for (int m = 0; m < 4; m += 1)
+ {
+   a = 0;
+   b -= e[k];
+   c[j][m] = f[j][6];
+ }
+  for (long i = 2; i < 4; ++i)
+foo (c[3][3]);
+}
-- 
2.44.0

build: Use of cargo not yet supported here in Canadian cross configurations (was: [PATCH] build: Check for cargo when building rust language)

[Thomas Schwinge]

Hi!

On 2024-04-15T13:14:42+0200, I wrote:
> On 2024-04-08T18:33:38+0200, pierre-emmanuel.pa...@embecosm.com wrote:
>> The rust frontend requires cargo to build some of it's components,
>
> In GCC upstream still: 's%requires%is going to require'.  ;-)
>
>> it's presence was not checked during configuration.
>
> After confirming the desired semantics/diagnostics, I've now pushed this
> to trunk branch in commit 3e1e73fc99584440e5967577f2049573eeaf4596
> "build: Check for cargo when building rust language".

On top of that, OK to push the attached
"build: Use of cargo not yet supported here in Canadian cross configurations"?


Grüße
 Thomas


>From eb38990b4147951dd21f19def43072368f782af5 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 15 Apr 2024 14:27:45 +0200
Subject: [PATCH] build: Use of cargo not yet supported here in Canadian cross
 configurations

..., until 
"'cargo' should build for the host system" is resolved.

Follow-up to commit 3e1e73fc99584440e5967577f2049573eeaf4596
"build: Check for cargo when building rust language".

	* configure.ac (have_cargo): Force to "no" in Canadian cross
	configurations
	* configure: Regenerate.
---
 configure| 13 +
 configure.ac | 12 
 2 files changed, 25 insertions(+)

diff --git a/configure b/configure
index e254aa132b5..e59a870b2bd 100755
--- a/configure
+++ b/configure
@@ -9179,6 +9179,19 @@ $as_echo "$as_me: WARNING: --enable-host-shared required to build $language" >&2
   ;;
 esac
 
+# Pre-conditions to consider whether cargo being supported.
+if test x"$have_cargo" = xyes \
+  && test x"$build" != x"$host"; then
+  # Until 
+  # "'cargo' should build for the host system" is resolved:
+  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: use of cargo not yet supported here in Canadian cross configurations" >&5
+$as_echo "$as_me: WARNING: use of cargo not yet supported here in Canadian cross configurations" >&2;}
+  have_cargo=no
+else
+  # Assume that cargo-produced object files are compatible with what
+  # we're going to build here.
+  :
+fi
 # Disable Rust if cargo is unavailable.
 case ${add_this_lang}:${language}:${have_cargo} in
   yes:rust:no)
diff --git a/configure.ac b/configure.ac
index 87205d0ac1f..4ab54431475 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2306,6 +2306,18 @@ directories, to avoid imposing the performance cost of
   ;;
 esac
 
+# Pre-conditions to consider whether cargo being supported.
+if test x"$have_cargo" = xyes \
+  && test x"$build" != x"$host"; then
+  # Until 
+  # "'cargo' should build for the host system" is resolved:
+  AC_MSG_WARN([use of cargo not yet supported here in Canadian cross configurations])
+  have_cargo=no
+else
+  # Assume that cargo-produced object files are compatible with what
+  # we're going to build here.
+  :
+fi
 # Disable Rust if cargo is unavailable.
 case ${add_this_lang}:${language}:${have_cargo} in
   yes:rust:no)
-- 
2.34.1

Re: [PATCH] RISC-V: Add VLS to mask vec_extract [PR114668].

[??????]

lgtm








 --Reply to Message--
 On Mon, Apr 15, 2024 20:43 PM Robin Dapp

Re: [PATCH] Guard longjmp in test to not inf loop [PR114720]

[Richard Biener]

On Mon, Apr 15, 2024 at 2:35 PM Jørgen Kvalsvik  wrote:
>
> Guard the longjmp to not infinitely loop. The longjmp (jump) function is
> called unconditionally to make test flow simpler, but the jump
> destination would return to a point in main that would call longjmp
> again. The longjmp is really there to exercise the then-branch of
> setjmp, to verify coverage is accurately counted in the presence of
> complex edges.

OK

> PR gcov-profile/114720
>
> gcc/testsuite/ChangeLog:
>
> * gcc.misc-tests/gcov-22.c: Guard longjmp to not loop.
> ---
>  gcc/testsuite/gcc.misc-tests/gcov-22.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.misc-tests/gcov-22.c 
> b/gcc/testsuite/gcc.misc-tests/gcov-22.c
> index 641791a7223..7ca78467ca3 100644
> --- a/gcc/testsuite/gcc.misc-tests/gcov-22.c
> +++ b/gcc/testsuite/gcc.misc-tests/gcov-22.c
> @@ -87,7 +87,19 @@ setdest ()
>  void
>  jump ()
>  {
> -longjmp (dest, 1);
> +/* Protect the longjmp so it will only be done once.  The whole purpose 
> of
> +   this function is to help test conditions and instrumentation around
> +   setjmp and its complex edges, as both branches should count towards
> +   coverage, even when one is taken through longjmp.  If the jump is not
> +   guarded it can cause an infinite loop as setdest returns to a point in
> +   main before jump (), leading to an infinite loop.  See PR
> +   gcov-profile/114720.  */
> +static int called_once = 0;
> +if (!called_once) /* conditions(suppress) */
> +{
> +   called_once = 1;
> +   longjmp (dest, 1);
> +}
>  }
>
>  int
> --
> 2.30.2
>

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

[Kito Cheng]

It's simple enough, so LGTM for trunk :)

Fei Gao  於 2024年4月15日 週一 14:38 寫道：

> When one of the two input operands is 0, ADD and IOR are functionally
> equivalent.
> ADD is slightly preferred over IOR because ADD has a higher likelihood
> of being implemented as a compressed instruction when compared to IOR.
> C.ADD uses the CR format with any of the 32 RVI registers availble,
> while C.OR uses the CA format with limit to just 8 of them.
>
> Conditional select, if zero case:
> rd = (rc == 0) ? rs1 : rs2
>
> before patch:
>
>   czero.nez rd, rs1, rc
>   czero.eqz rtmp, rs2, rc
>   or rd, rd, rtmp
>
> after patch:
>
>   czero.eqz rd, rs1, rc
>   czero.nez rtmp, rs2, rc
>   add rd, rd, rtmp
>
> Same trick applies for the conditional select, if non-zero case:
> rd = (rc != 0) ? rs1 : rs2
>
> riscv-gnu-toolchain regression tests have been passed with no new failure.
> ---
>  gcc/config/riscv/riscv.cc|  2 +-
>  .../gcc.target/riscv/zicond-prefer-add-to-or.c   | 16 
>  2 files changed, 17 insertions(+), 1 deletion(-)
>  create mode 100644
> gcc/testsuite/gcc.target/riscv/zicond-prefer-add-to-or.c
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index e5f00806bb9..93c736549c9 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -4709,7 +4709,7 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx
> cons, rtx alt)
>   gen_rtx_IF_THEN_ELSE (mode, cond1,
> CONST0_RTX (mode),
> alt)));
> - riscv_emit_binary (IOR, dest, reg1, reg2);
> + riscv_emit_binary (PLUS, dest, reg1, reg2);
>   return true;
> }
>  }
> diff --git a/gcc/testsuite/gcc.target/riscv/zicond-prefer-add-to-or.c
> b/gcc/testsuite/gcc.target/riscv/zicond-prefer-add-to-or.c
> new file mode 100644
> index 000..f3f7beb0b5e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/zicond-prefer-add-to-or.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gc_zicond -mabi=lp64d -mbranch-cost=4" {
> target { rv64 } } } */
> +/* { dg-options "-march=rv32gc_zicond -mabi=ilp32f -mbranch-cost=4" {
> target { rv32 } } } */
> +/* { dg-skip-if "" { *-*-* } {"-O0" "-Og" "-Os" "-Oz"} } */
> +
> +long cond_select_if_zero(long a, long b, long c) {
> +  return a == 0 ? c : b;
> +}
> +
> +long cond_select_if_non_zero(long a, long b, long c) {
> +  return a != 0 ? c : b;
> +}
> +
> +/* { dg-final { scan-assembler-times {add\t}  2 } } */
> +/* { dg-final { scan-assembler-not {or\t} } } */
> +
> --
> 2.17.1
>
>

[PATCH] libstdc++: Update baseline symbols for riscv64-linux

[Andreas Schwab]

* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
---
 .../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4 
 1 file changed, 4 insertions(+)

diff --git 
a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
index 9423cfb8efc..9229ad33458 100644
--- a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
@@ -499,6 +499,10 @@ FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
 FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
 FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
 FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
 FUNC:_ZNKSt12strstreambuf6pcountEv@@GLIBCXX_3.4
-- 
2.44.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

[Jeff Law]

On 4/15/24 6:58 AM, Kito Cheng wrote:

It's simple enough, so LGTM for trunk :)
We're already doing this internally.  I just hadn't submitted it due to 
being deep into stage4.


Jeff

[PATCH] m68k: Quiet up cppcheck warning [PR114689]

[Jakub Jelinek]

Hi!

cppcheck apparently warns on the | !!sticky part of the expression and
using | (!!sticky) quiets it up (it is correct as is).
The following patch adds the ()s, and also adds them around mant >> 1 just
in case it makes it clearer to all readers that the expression is parsed
that way already.

Ok for trunk?

2024-04-15  Jakub Jelinek  

PR libgcc/114689
* config/m68k/fpgnulib.c (__truncdfsf2): Add parentheses around
!!sticky bitwise or operand to quiet up cppcheck.  Add parentheses
around mant >> 1 bitwise or operand.

--- libgcc/config/m68k/fpgnulib.c.jj2023-11-11 08:52:20.927838065 +0100
+++ libgcc/config/m68k/fpgnulib.c   2024-04-15 16:29:57.810026425 +0200
@@ -302,7 +302,7 @@ __truncdfsf2 (double a1)
   if (exp == EXPDMASK - EXCESSD + EXCESS)
 {
   exp = EXPMASK;
-  mant = mant >> 1 | (mant & 1) | !!sticky;
+  mant = (mant >> 1) | (mant & 1) | (!!sticky);
 }
   else
 {

Jakub

Re: [PATCH] m68k: Quiet up cppcheck warning [PR114689]

[Jeff Law]

On 4/15/24 8:43 AM, Jakub Jelinek wrote:

Hi!

cppcheck apparently warns on the | !!sticky part of the expression and
using | (!!sticky) quiets it up (it is correct as is).
The following patch adds the ()s, and also adds them around mant >> 1 just
in case it makes it clearer to all readers that the expression is parsed
that way already.

Ok for trunk?

2024-04-15  Jakub Jelinek  

PR libgcc/114689
* config/m68k/fpgnulib.c (__truncdfsf2): Add parentheses around
!!sticky bitwise or operand to quiet up cppcheck.  Add parentheses
around mant >> 1 bitwise or operand.

OK
jeff

Re: [PATCH] libstdc++: Update baseline symbols for riscv64-linux

[Jonathan Wakely]

On Mon, 15 Apr 2024 at 14:01, Andreas Schwab wrote:
>
>
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.

OK for trunk and gcc-13, thanks.

> ---
>  .../config/abi/post/riscv64-linux-gnu/baseline_symbols.txt| 4 
>  1 file changed, 4 insertions(+)
>
> diff --git 
> a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 
> b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
> index 9423cfb8efc..9229ad33458 100644
> --- a/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
> +++ b/libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt
> @@ -499,6 +499,10 @@ FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
>  FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
>  FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
>  FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
>  FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
>  FUNC:_ZNKSt12strstreambuf6pcountEv@@GLIBCXX_3.4
> --
> 2.44.0
>
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>

[wwwdocs] gcc-14/changes.html + projects/gomp/: Fix OpenMP/OpenACC changes section/anchor

[Tobias Burnus]

When clicking on the GCC..1x links at 
https://gcc.gnu.org/projects/gomp/#omp5.0 , I noticed that the GCC 13 
and 14 links did not link to the OpenMP changes.


It turned out that in GCC 12 and before (see commit message for 
details), the OpenMP and OpenACC changes are under "New Languages and 
Language-Specific Improvements" – while for GCC 13 and 14 they are under 
"General Improvements"


Example: GCC 12 – https://gcc.gnu.org/gcc-12/changes.html#languages 
(directly under  and before the first  entry ["Ada"]).


GCC 13: https://gcc.gnu.org/gcc-13/changes.html#general

The attached patch keeps GCC 13 for backward compatibility but moves 
them for GCC 14 "back" to languages.


To fix the links at projects/gomp/, it therefore it updates the page 
anchors to 'general'.


* * *

Comments or remarks?

Tobias
gcc-14/changes.html + projects/gomp/: Fix OpenMP/OpenACC changes section/anchor

In earlier release notes, OpenMP and OpenACC changes were under "New
Languages and Language specific improvements", either directly under that
section as in 4.2, 4.4, 4.7, 4.9, 5, 6 (+ c-family + Fortran), 10, 11, and 12
or under a subsection in 4.5 (Fortran), 4.8 (C++), 7 (Fortran), 9 (c-family).

In gcc-13, the OpenMP and OpenACC ended up by chance under "General
Improvements", which gcc-14 replicated.

This commit does not touch gcc-13 to avoid breaking links, but it corrects the
anchor used in the links to GCC 13 in projects/gomp/.

However, for GCC 14, it moves the OpenMP/OpenACC changes to the language
section.

 htdocs/gcc-14/changes.html  | 135 
 htdocs/projects/gomp/index.html |  44 ++---
 2 files changed, 91 insertions(+), 88 deletions(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index b4c602a5..6035ae37 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -59,6 +59,75 @@ a work-in-progress.
 
 General Improvements
 
+
+  For offload-device code generated via OpenMP and OpenACC, the math
+  and the Fortran runtime libraries will now automatically be linked,
+  when the user or compiler links them on the host side. Thus, it is no
+  longer required to explicitly pass -lm and/or
+  -lgfortran to the offload-device linker using the https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload-options";
+  >-foffload-options= flag.
+  
+  
+New configure options: --enable-host-pie, to build the
+compiler executables as PIE; and --enable-host-bind-now,
+to link the compiler executables with -Wl,-z,now in order
+to enable additional hardening.
+  
+  
+New option
+https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fhardened";>-fhardened,
+an umbrella option that enables a set of hardening flags.
+The options it enables can be displayed using the
+--help=hardened option.
+  
+  
+New option
+https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fharden-control-flow-redundancy";>-fharden-control-flow-redundancy,
+to verify, at the end of functions, that the visited basic blocks
+correspond to a legitimate execution path, so as to detect and
+prevent attacks that transfer control into the middle of
+functions.
+  
+  
+New type attribute
+https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-hardbool-type-attribute";>hardbool,
+for C and Ada.  Hardened
+booleans take user-specified representations for true
+and false, presumably with higher hamming distance
+than standard booleans, and get verified at every use, detecting
+memory corruption and some malicious attacks.
+  
+  
+New type attribute
+https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-strub-type-attribute";>strub
+to control stack scrubbing
+properties of functions and variables.  The stack frame used by
+functions marked with the attribute gets zeroed-out upon returning
+or exception escaping.  Scalar variables marked with the attribute
+cause functions contaning or accessing them to get stack scrubbing
+enabled implicitly.
+  
+  
+New option
+https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline-stringops";>-finline-stringops,
+to force inline
+expansion of memcmp, memcpy,
+memmove and memset, even when that is
+not an optimization, to avoid relying on library
+implementations.
+  
+  
+
+New function attribute
+https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-null_005fterminated_005fstring_005farg-function-attribute";> null_terminated_string_arg(PARAM_IDX)
+for indicating parameters that are expected to be null-terminated
+strings.
+  
+
+
+New Languages and Language specific improvements
+
 
   https://gcc.gnu.org/projects/gomp/";>OpenMP
   
@@ -136,73 +205,7 @@ a work-in-progress.
   acc_memcpy_from_device_async.
   
   
-  For offload-device code g

Re: build: Use of cargo not yet supported here in Canadian cross configurations

[Pierre-Emmanuel Patry]

Hello,

On 4/15/24 2:44 PM, Thomas Schwinge wrote:

On top of that, OK to push the attached
"build: Use of cargo not yet supported here in Canadian cross configurations"?


This additional patch looks good. I wonder whether we should enable 
canadian cross in the future with cargo or simply wait for gcc to be 
able to compile those components entirely.


Regards,

--
Patry Pierre-Emmanuel
Compiler Engineer - Embecosm



OpenPGP_0xD006124B2A7AEA23.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

AVR: Add some more avrxmega3 devices

[Georg-Johann Lay]

Applied the following patch..

Johann

--

AVR: Add 8 more avrxmega3 MCUs.

gcc/
* config/avr/avr-mcus.def: Add: avr16du14, avr16du20, 
avr16du28,

avr16du32, avr32du14, avr32du20, avr32du28,  avr32du32.
* doc/avr-mmcu.texi: Rebuild.

diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index 27812d441f7..068875a2c60 100644
--- a/gcc/config/avr/avr-mcus.def
+++ b/gcc/config/avr/avr-mcus.def
@@ -379,6 +379,10 @@ AVR_MCU ("avr16dd14",ARCH_AVRXMEGA3, 
AVR_ISA_NONE,  "__AVR_AVR16DD14__",
 AVR_MCU ("avr16dd20",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DD20__",   0x7800, 0x0, 0x4000, 0x8000)
 AVR_MCU ("avr16dd28",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DD28__",   0x7800, 0x0, 0x4000, 0x8000)
 AVR_MCU ("avr16dd32",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DD32__",   0x7800, 0x0, 0x4000, 0x8000)
+AVR_MCU ("avr16du14",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DU14__",   0x7800, 0x0, 0x4000, 0x8000)
+AVR_MCU ("avr16du20",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DU20__",   0x7800, 0x0, 0x4000, 0x8000)
+AVR_MCU ("avr16du28",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DU28__",   0x7800, 0x0, 0x4000, 0x8000)
+AVR_MCU ("avr16du32",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16DU32__",   0x7800, 0x0, 0x4000, 0x8000)
 AVR_MCU ("avr32da28",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DA28__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr32da32",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DA32__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr32da48",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DA48__",   0x7000, 0x0, 0x8000, 0x8000)
@@ -389,6 +393,10 @@ AVR_MCU ("avr32dd14",ARCH_AVRXMEGA3, 
AVR_ISA_NONE,  "__AVR_AVR32DD14__",
 AVR_MCU ("avr32dd20",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DD20__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr32dd28",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DD28__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr32dd32",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DD32__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32du14",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DU14__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32du20",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DU20__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32du28",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DU28__",   0x7000, 0x0, 0x8000, 0x8000)
+AVR_MCU ("avr32du32",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR32DU32__",   0x7000, 0x0, 0x8000, 0x8000)
 AVR_MCU ("avr16eb14",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16EB14__",   0x7800, 0x0, 0x4000, 0x8000)
 AVR_MCU ("avr16eb20",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16EB20__",   0x7800, 0x0, 0x4000, 0x8000)
 AVR_MCU ("avr16eb28",ARCH_AVRXMEGA3, AVR_ISA_NONE, 
"__AVR_AVR16EB28__",   0x7800, 0x0, 0x4000, 0x8000)

diff --git a/gcc/doc/avr-mmcu.texi b/gcc/doc/avr-mmcu.texi
index dcbf4ef7247..671e66e7ffb 100644
--- a/gcc/doc/avr-mmcu.texi
+++ b/gcc/doc/avr-mmcu.texi
@@ -54,7 +54,7 @@

 @item @anchor{avrxmega3}avrxmega3
 ``XMEGA'' devices with up to 64@tie{}KiB of combined program memory 
and RAM, and with program memory visible in the RAM address space.
-@*@var{mcu}@tie{}= @code{attiny202}, @code{attiny204}, 
@code{attiny212}, @code{attiny214}, @code{attiny402}, @code{attiny404}, 
@code{attiny406}, @code{attiny412}, @code{attiny414}, @code{attiny416}, 
@code{attiny416auto}, @code{attiny417}, @code{attiny424}, 
@code{attiny426}, @code{attiny427}, @code{attiny804}, @code{attiny806}, 
@code{attiny807}, @code{attiny814}, @code{attiny816}, @code{attiny817}, 
@code{attiny824}, @code{attiny826}, @code{attiny827}, @code{attiny1604}, 
@code{attiny1606}, @code{attiny1607}, @code{attiny1614}, 
@code{attiny1616}, @code{attiny1617}, @code{attiny1624}, 
@code{attiny1626}, @code{attiny1627}, @code{attiny3214}, 
@code{attiny3216}, @code{attiny3217}, @code{attiny3224}, 
@code{attiny3226}, @code{attiny3227}, @code{atmega808}, 
@code{atmega809}, @code{atmega1608}, @code{atmega1609}, 
@code{atmega3208}, @code{atmega3209}, @code{atmega4808}, 
@code{atmega4809}, @code{avr16dd14}, @code{avr16dd20}, @code{avr16dd28}, 
@code{avr16dd32}, @code{avr16ea28}, @code{avr16ea32}, @code{avr16ea48}, 
@code{avr16eb14}, @code{avr16eb20}, @code{avr16eb28}, @code{avr16eb32}, 
@code{avr32da28}, @code{avr32da32}, @code{avr32da48}, @code{avr32db28}, 
@code{avr32db32}, @code{avr32db48}, @code{avr32dd14}, @code{avr32dd20}, 
@code{avr32dd28}, @code{avr32dd32}, @code{avr32ea28}, @code{avr32ea32}, 
@code{avr32ea48}.
+@*@var{mcu}@tie{}= @code{attiny202}, @code{attiny204}, 
@code{attiny212}, @code{attiny214}, @code{attiny402}, @code{attiny404}, 
@code{attiny406}, @code{attiny412}, @code{attiny414}, @code{attiny416}, 
@code{attiny416auto}, @code{attiny417}, @code{attiny424}, 
@code{attiny426}, @code{attiny427}, @code{attiny804}, @code{attiny806}, 
@code{attiny807}, @code{attiny814}, @code{attiny816},

Re: [PATCH] gotools: Workaround non-reproduceability of automake

[Ian Lance Taylor]

On Mon, Apr 15, 2024 at 5:42 AM Jakub Jelinek  wrote:
>
> 2024-04-15  Jakub Jelinek  
>
> * Makefile.am (install-exec-local, uninstall-local): Add goals
> on the else branch of if NATIVE to ensure reproducibility.
> * Makefile.in: Regenerate.

This is OK.  Go ahead and commit.  Thanks.

Ian

Re: [wwwdocs] gcc-14/changes.html (AMD GCN): Mention gfx1036 support

[Tobias Burnus]

Richard Biener wrote:

I do wonder whether hot-patching the ELF header from the libgomp plugin
with the actual micro-subarch would be possible to make the driver happy.


For completeness, there is also the possibility to play with an 
environment variable as in HSA_OVERRIDE_GFX_VERSION=9.0.0 or 
HSA_OVERRIDE_GFX_VERSION=11.0.0


Tobias

Re: [PATCH] Update GCC 14.1 library versions in docs

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:51, Jonathan Wakely wrote:
>
> On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When we are already touching this topic, here is a patch like r13-5126
> > which documents the upcoming release symbol versions in the documentation.
> >
> > Ok for trunk?
>
> OK, thanks.
>
> >
> > 2024-04-11  Jakub Jelinek  
> >
> > * doc/xml/manual/abi.xml: Add latest library versions.
> > * doc/html/manual/abi.html: Regenerate.
> >

I'll push this too.
commit 24665d21afd29ac427482243852cb8940bc813d0
Author: Jonathan Wakely 
Date:   Mon Apr 15 16:38:08 2024

libstdc++: Update libstdc++.so versioning history for 14.1.0 release

We can replace "GCC " with "GCC 14.1.0" now that we're nearing the
release.

libstdc++-v3/ChangeLog:

* doc/xml/manual/abi.xml: Replace "" with "14.1.0".
* doc/html/manual/abi.html: Regenerate.

diff --git a/libstdc++-v3/doc/html/manual/abi.html 
b/libstdc++-v3/doc/html/manual/abi.html
index 3075477cc34..0eb6a12a501 100644
--- a/libstdc++-v3/doc/html/manual/abi.html
+++ b/libstdc++-v3/doc/html/manual/abi.html
@@ -110,7 +110,7 @@ compatible.
has the same filename and DT_SONAME as the
preceding release.
   It is versioned as follows:
-GCC 3.0.0: 
libstdc++.so.3.0.0GCC 3.0.1: 
libstdc++.so.3.0.1GCC 3.0.2: 
libstdc++.so.3.0.2GCC 3.0.3: 
libstdc++.so.3.0.2 (See Note 1)GCC 3.0.4: 
libstdc++.so.3.0.4GCC 3.1.0: 
libstdc++.so.4.0.0 (Incompatible with 
previous)GCC 3.1.1: 
libstdc++.so.4.0.1GCC 3.2.0: 
libstdc++.so.5.0.0 (Incompatible with 
previous)GCC 3.2.1: 
libstdc++.so.5.0.1GCC 3.2.2: 
libstdc++.so.5.0.2GCC 3.2.3: 
libstdc++.so.5.0.3 (See Note 2)GCC 3.3.0: 
libstdc++.so.5.0.4GCC 3.3.1: 
libstdc++.so.5.0.5GCC 3.4.0: 
libstdc++.so.6.0.0 (Incompatible with 
previous)GCC 3.4.1: 
libstdc++.so.6.0.1GCC 3.4.2: 
libstdc++.so.6.0.2GCC 3.4.3: 
libstdc++.so.6.0.3GCC 4.0.0: 
libstdc++.so.6.0.4GCC 4.0.1: 
libstdc++.so.6.0.5GCC 4.0.2: 
libstdc++.so.6.0.6GCC 4.0.3: 
libstdc++.so.6.0.7GCC 4.1.0: 
libstdc++.so.6.0.7GCC 4.1.1: 
libstdc++.so.6.0.8GCC 4.2.0: 
libstdc++.so.6.0.9GCC 4.2.1: 
libstdc++.so.6.0.9 (See Note 3)GCC 4.2.2: 
libstdc++.so.6.0.9GCC 4.3.0: 
libstdc++.so.6.0.10GCC 4.4.0: 
libstdc++.so.6.0.11GCC 4.4.1: 
libstdc++.so.6.0.12GCC 4.4.2: 
libstdc++.so.6.0.13GCC 4.5.0: 
libstdc++.so.6.0.14GCC 4.6.0: 
libstdc++.so.6.0.15GCC 4.6.1: 
libstdc++.so.6.0.16GCC 4.7.0: 
libstdc++.so.6.0.17GCC 4.8.0: 
libstdc++.so.6.0.18GCC 4.8.3: 
libstdc++.so.6.0.19GCC 4.9.0: 
libstdc++.so.6.0.20GCC 5.1.0: 
libstdc++.so.6.0.21GCC 6.1.0: 
libstdc++.so.6.0.22GCC 7.1.0: 
libstdc++.so.6.0.23GCC 7.2.0: 
libstdc++.so.6.0.24GCC 8.1.0: 
libstdc++.so.6.0.25GCC 9.1.0: 
libstdc++.so.6.0.26GCC 9.2.0: 
libstdc++.so.6.0.27GCC 9.3.0: 
libstdc++.so.6.0.28GCC 10.1.0: 
libstdc++.so.6.0.28GCC 11.1.0: 
libstdc++.so.6.0.29GCC 12.1.0: 
libstdc++.so.6.0.30GCC 13.1.0: 
libstdc++.so.6.0.31GCC 13.2.0: 
libstdc++.so.6.0.32GCC : 
libstdc++.so.6.0.33
+GCC 3.0.0: 
libstdc++.so.3.0.0GCC 3.0.1: 
libstdc++.so.3.0.1GCC 3.0.2: 
libstdc++.so.3.0.2GCC 3.0.3: 
libstdc++.so.3.0.2 (See Note 1)GCC 3.0.4: 
libstdc++.so.3.0.4GCC 3.1.0: 
libstdc++.so.4.0.0 (Incompatible with 
previous)GCC 3.1.1: 
libstdc++.so.4.0.1GCC 3.2.0: 
libstdc++.so.5.0.0 (Incompatible with 
previous)GCC 3.2.1: 
libstdc++.so.5.0.1GCC 3.2.2: 
libstdc++.so.5.0.2GCC 3.2.3: 
libstdc++.so.5.0.3 (See Note 2)GCC 3.3.0: 
libstdc++.so.5.0.4GCC 3.3.1: 
libstdc++.so.5.0.5GCC 3.4.0: 
libstdc++.so.6.0.0 (Incompatible with 
previous)GCC 3.4.1: 
libstdc++.so.6.0.1GCC 3.4.2: 
libstdc++.so.6.0.2GCC 3.4.3: 
libstdc++.so.6.0.3GCC 4.0.0: 
libstdc++.so.6.0.4GCC 4.0.1: 
libstdc++.so.6.0.5GCC 4.0.2: 
libstdc++.so.6.0.6GCC 4.0.3: 
libstdc++.so.6.0.7GCC 4.1.0: 
libstdc++.so.6.0.7GCC 4.1.1: 
libstdc++.so.6.0.8GCC 4.2.0: 
libstdc++.so.6.0.9GCC 4.2.1: 
libstdc++.so.6.0.9 (See Note 3)GCC 4.2.2: 
libstdc++.so.6.0.9GCC 4.3.0: 
libstdc++.so.6.0.10GCC 4.4.0: 
libstdc++.so.6.0.11GCC 4.4.1: 
libstdc++.so.6.0.12GCC 4.4.2: 
libstdc++.so.6.0.13GCC 4.5.0: 
libstdc++.so.6.0.14GCC 4.6.0: 
libstdc++.so.6.0.15GCC 4.6.1: 
libstdc++.so.6.0.16GCC 4.7.0: 
libstdc++.so.6.0.17GCC 4.8.0: 
libstdc++.so.6.0.18GCC 4.8.3: 
libstdc++.so.6.0.19GCC 4.9.0: 
libstdc++.so.6.0.20GCC 5.1.0: 
libstdc++.so.6.0.21GCC 6.1.0: 
libstdc++.so.6.0.22GCC 7.1.0: 
libstdc++.so.6.0.23GCC 7.2.0: 
libstdc++.so.6.0.24GCC 8.1.0: 
libstdc++.so.6.0.25GCC 9.1.0: 
libstdc++.so.6.0.26GCC 9.2.0: 
libstdc++.so.6.0.27GCC 9.3.0: 
libstdc++.so.6.0.28GCC 10.1.0: 
libstdc++.so.6.0.28GCC 11.1.0: 
libstdc++.so.6.0.29GCC 12.1.0: 
libstdc++.so.6.0.30GCC 13.1.0: 
libstdc++.so.6.0.31GCC 13.2.0: 
libstdc++.so.6.0.32GCC 14.1.0: 
libstdc++.so.6.0.33
   Note 1: Error should be libstdc++.so.3.0.3.
 
   Note 2: Not strictly required.
diff --git a/libstdc++-v3/doc/xml/manual/abi.xml 
b/libstdc++-v3/doc/xml/manual/abi.xml
index ef66faa8224..a4ce866b884 100644
--- a/libstdc++-v3/doc/xml/manual/abi.xml
+++ b/libstdc++-v3/doc/xml/manual/abi.xml
@@ -281,7 +28

Re: [PATCH 2/4] libstdc++: Add std::reference_wrapper comparison operators for C++26

[Jonathan Wakely]

Pushed to trunk now.



On Wed, 10 Apr 2024 at 09:53, Jonathan Wakely  wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++26 it seems OK for trunk now.
>
> -- >8 --
>
> This C++26 change was just approved in Tokyo, in P2944R3. It adds
> operator== and operator<=> overloads to std::reference_wrapper.
>
> The operator<=> overloads in the paper cause compilation errors for any
> type without <=> so they're implemented here with deduced return types
> and constrained by a requires clause.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/refwrap.h (reference_wrapper): Add comparison
> operators as proposed by P2944R3.
> * include/bits/version.def (reference_wrapper): Define.
> * include/bits/version.h: Regenerate.
> * include/std/functional: Enable feature test macro.
> * testsuite/20_util/reference_wrapper/compare.cc: New test.
> ---
>  libstdc++-v3/include/bits/refwrap.h   | 45 +
>  libstdc++-v3/include/bits/version.def |  8 ++
>  libstdc++-v3/include/bits/version.h   | 10 ++
>  libstdc++-v3/include/std/functional   |  1 +
>  .../20_util/reference_wrapper/compare.cc  | 95 +++
>  5 files changed, 159 insertions(+)
>  create mode 100644 
> libstdc++-v3/testsuite/20_util/reference_wrapper/compare.cc
>
> diff --git a/libstdc++-v3/include/bits/refwrap.h 
> b/libstdc++-v3/include/bits/refwrap.h
> index 2d4338b718f..fd1cc2b63e6 100644
> --- a/libstdc++-v3/include/bits/refwrap.h
> +++ b/libstdc++-v3/include/bits/refwrap.h
> @@ -38,6 +38,10 @@
>  #include 
>  #include  // for unary_function and binary_function
>
> +#if __glibcxx_reference_wrapper >= 202403L // >= C++26
> +# include 
> +#endif
> +
>  namespace std _GLIBCXX_VISIBILITY(default)
>  {
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
> @@ -358,6 +362,47 @@ _GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, 
> true_type)
>  #endif
>   return std::__invoke(get(), std::forward<_Args>(__args)...);
> }
> +
> +#if __glibcxx_reference_wrapper >= 202403L // >= C++26
> +  // [refwrap.comparisons], comparisons
> +  [[nodiscard]]
> +  friend constexpr bool
> +  operator==(reference_wrapper __x, reference_wrapper __y)
> +  requires requires { { __x.get() == __y.get() } -> 
> convertible_to; }
> +  { return __x.get() == __y.get(); }
> +
> +  [[nodiscard]]
> +  friend constexpr bool
> +  operator==(reference_wrapper __x, const _Tp& __y)
> +  requires requires { { __x.get() == __y } -> convertible_to; }
> +  { return __x.get() == __y; }
> +
> +  [[nodiscard]]
> +  friend constexpr bool
> +  operator==(reference_wrapper __x, reference_wrapper __y)
> +  requires (!is_const_v<_Tp>)
> +   && requires { { __x.get() == __y.get() } -> convertible_to; }
> +  { return __x.get() == __y.get(); }
> +
> +  [[nodiscard]]
> +  friend constexpr auto
> +  operator<=>(reference_wrapper __x, reference_wrapper<_Tp> __y)
> +  requires requires { __detail::__synth3way(__x.get(), __y.get()); }
> +  { return __detail::__synth3way(__x.get(), __y.get()); }
> +
> +  [[nodiscard]]
> +  friend constexpr auto
> +  operator<=>(reference_wrapper __x, const _Tp& __y)
> +  requires requires { __detail::__synth3way(__x.get(), __y); }
> +  { return __detail::__synth3way(__x.get(), __y); }
> +
> +  [[nodiscard]]
> +  friend constexpr auto
> +  operator<=>(reference_wrapper __x, reference_wrapper __y)
> +  requires (!is_const_v<_Tp>)
> +   && requires { __detail::__synth3way(__x.get(), __y.get()); }
> +  { return __detail::__synth3way(__x.get(), __y.get()); }
> +#endif
>  };
>
>  #if __cpp_deduction_guides
> diff --git a/libstdc++-v3/include/bits/version.def 
> b/libstdc++-v3/include/bits/version.def
> index 5ad44941bff..5c0477fb61e 100644
> --- a/libstdc++-v3/include/bits/version.def
> +++ b/libstdc++-v3/include/bits/version.def
> @@ -1760,6 +1760,14 @@ ftms = {
>};
>  };
>
> +ftms = {
> +  name = reference_wrapper;
> +  values = {
> +v = 202403;
> +cxxmin = 26;
> +  };
> +};
> +
>  ftms = {
>name = saturation_arithmetic;
>values = {
> diff --git a/libstdc++-v3/include/bits/version.h 
> b/libstdc++-v3/include/bits/version.h
> index 460a3e0116a..65e708c73fb 100644
> --- a/libstdc++-v3/include/bits/version.h
> +++ b/libstdc++-v3/include/bits/version.h
> @@ -1963,6 +1963,16 @@
>  #endif /* !defined(__cpp_lib_ratio) && defined(__glibcxx_want_ratio) */
>  #undef __glibcxx_want_ratio
>
> +#if !defined(__cpp_lib_reference_wrapper)
> +# if (__cplusplus >  202302L)
> +#  define __glibcxx_reference_wrapper 202403L
> +#  if defined(__glibcxx_want_all) || 
> defined(__glibcxx_want_reference_wrapper)
> +#   define __cpp_lib_reference_wrapper 202403L
> +#  endif
> +# endif
> +#endif /* !defined(__cpp_lib_reference_wrapper) && 
> defined(__glibcxx_want_reference_wrapper) */
> +#undef __glibcxx_want_reference_wrapper
> +
>  #if !defined(__cpp_lib_saturati

Re: [PATCH 1/4] libstdc++: Heterogeneous std::pair comparisons [PR113386]

[Jonathan Wakely]

Pushed to trunk now.

On Wed, 10 Apr 2024 at 09:51, Jonathan Wakely  wrote:
>
> Tested x86_64-linux.
>
> Since this only affects C++20 and later it seems OK for trunk now.
>
> -- >8 --
>
> I'm only treating this as a DR for C++20 for now, because it's less work
> and only requires changes to operator== and operator<=>. To do this for
> older standards would require changes to the six relational operators
> used pre-C++20.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/113386
> * include/bits/stl_pair.h (operator==, operator<=>): Support
> heterogeneous comparisons, as per LWG 3865.
> * testsuite/20_util/pair/comparison_operators/lwg3865.cc: New
> test.
> ---
>  libstdc++-v3/include/bits/stl_pair.h  | 32 ++-
>  .../pair/comparison_operators/lwg3865.cc  | 15 +
>  2 files changed, 39 insertions(+), 8 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
>
> diff --git a/libstdc++-v3/include/bits/stl_pair.h 
> b/libstdc++-v3/include/bits/stl_pair.h
> index 4f5c8389fa6..45317417c9c 100644
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -1000,23 +1000,39 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>template pair(_T1, _T2) -> pair<_T1, _T2>;
>  #endif
>
> -  /// Two pairs of the same type are equal iff their members are equal.
> -  template
> +#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
> +  // _GLIBCXX_RESOLVE_LIB_DEFECTS
> +  // 3865. Sorting a range of pairs
> +
> +  /// Two pairs are equal iff their members are equal.
> +  template
>  inline _GLIBCXX_CONSTEXPR bool
> -operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
> +operator==(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
>  { return __x.first == __y.first && __x.second == __y.second; }
>
> -#if __cpp_lib_three_way_comparison && __cpp_lib_concepts
> -  template
> -constexpr common_comparison_category_t<__detail::__synth3way_t<_T1>,
> -  __detail::__synth3way_t<_T2>>
> -operator<=>(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
> +  /** Defines a lexicographical order for pairs.
> +   *
> +   * For two pairs of comparable types, `P` is ordered before `Q` if
> +   * `P.first` is less than `Q.first`, or if `P.first` and `Q.first`
> +   * are equivalent (neither is less than the other) and `P.second` is
> +   * less than `Q.second`.
> +  */
> +  template
> +constexpr common_comparison_category_t<__detail::__synth3way_t<_T1, _U1>,
> +  __detail::__synth3way_t<_T2, _U2>>
> +operator<=>(const pair<_T1, _T2>& __x, const pair<_U1, _U2>& __y)
>  {
>if (auto __c = __detail::__synth3way(__x.first, __y.first); __c != 0)
> return __c;
>return __detail::__synth3way(__x.second, __y.second);
>  }
>  #else
> +  /// Two pairs of the same type are equal iff their members are equal.
> +  template
> +inline _GLIBCXX_CONSTEXPR bool
> +operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
> +{ return __x.first == __y.first && __x.second == __y.second; }
> +
>/** Defines a lexicographical order for pairs.
> *
> * For two pairs of the same type, `P` is ordered before `Q` if
> diff --git 
> a/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc 
> b/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
> new file mode 100644
> index 000..2bbd54af192
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/20_util/pair/comparison_operators/lwg3865.cc
> @@ -0,0 +1,15 @@
> +// { dg-do run { target c++20 } }
> +
> +// LWG 3865. Sorting a range of pairs
> +
> +#include 
> +#include 
> +
> +int main()
> +{
> +  std::pair p(1, 2);
> +  std::pair p2(p.first, p.second);
> +  VERIFY( p == p2 );
> +  VERIFY( p <= p2 );
> +  VERIFY( p >= p2 );
> +}
> --
> 2.44.0
>

Re: [PATCH v2] libstdc++: Fix infinite loop in std::istream::ignore(n, delim) [PR93672]

[Jonathan Wakely]

Pushed to trunk now.


On Mon, 8 Apr 2024 at 17:53, Jonathan Wakely  wrote:
>
> Patch v2.
>
> I realised that it's not only negative delim values that cause the
> problem, but also ones greater than CHAR_MAX. Calling ignore(n, 'a'+256)
> will cause traits_type::find to match 'a' but then the eq_int_type
> comparison will fail because (int)'a' != (int)('a' + 256).
>
> This version of the patch calls to_int_type on the delim and if that
> alters the value, it's never going to match so skip the loop that tries
> to find it and just ignore up to n chars instead.
>
> Tested x86_64linux and aarch64-linux.
>
> -- >8 --
>
> A negative delim value passed to std::istream::ignore can never match
> any character in the stream, because the comparison is done using
> traits_type::eq_int_type(sb->sgetc(), delim) and sgetc() never returns
> negative values (except at EOF). The optimized version of ignore for the
> std::istream specialization uses traits_type::find to locate the delim
> character in the streambuf, which _can_ match a negative delim on
> platforms where char is signed, but then we do another comparison using
> eq_int_type which fails. The code then keeps looping forever, with
> traits_type::find locating the character and traits_type::eq_int_type
> saying it's not a match, so traits_type::find is used again and finds
> the same character again.
>
> A possible fix would be to check with eq_int_type after a successful
> find, to see whether we really have a match. However, that would be
> suboptimal since we know that a negative delimiter will never match
> using eq_int_type. So a better fix is to adjust the check at the top of
> the function that handles delim==eof(), so that we treat all negative
> delim values as equivalent to EOF. That way we don't bother using find
> to search for something that will never match with eq_int_type.
>
> The version of ignore in the primary template doesn't need a change,
> because it doesn't use traits_type::find, instead characters are
> extracted one-by-one and always matched using eq_int_type. That avoids
> the inconsistency between find and eq_int_type. The specialization for
> std::wistream does use traits_type::find, but traits_type::to_int_type
> is equivalent to an implicit conversion from wchar_t to wint_t, so
> passing a wchar_t directly to ignore without using to_int_type works.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/93672
> * src/c++98/istream.cc (istream::ignore(streamsize, int_type)):
> Treat all negative delimiter values as eof().
> * testsuite/27_io/basic_istream/ignore/char/93672.cc: New test.
> * testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc: New
> test.
> ---
>  libstdc++-v3/src/c++98/istream.cc |  13 ++-
>  .../27_io/basic_istream/ignore/char/93672.cc  | 101 ++
>  .../basic_istream/ignore/wchar_t/93672.cc |  34 ++
>  3 files changed, 146 insertions(+), 2 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
>  create mode 100644 
> libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/93672.cc
>
> diff --git a/libstdc++-v3/src/c++98/istream.cc 
> b/libstdc++-v3/src/c++98/istream.cc
> index 07ac739c26a..d1bff2b 100644
> --- a/libstdc++-v3/src/c++98/istream.cc
> +++ b/libstdc++-v3/src/c++98/istream.cc
> @@ -112,8 +112,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  basic_istream::
>  ignore(streamsize __n, int_type __delim)
>  {
> -  if (traits_type::eq_int_type(__delim, traits_type::eof()))
> -   return ignore(__n);
> +  {
> +   // If conversion to int_type changes the value then __delim does not
> +   // correspond to a value of type char_type, and so will never match
> +   // a character extracted from the input sequence. Just use ignore(n).
> +   const int_type chk_delim = traits_type::to_int_type(__delim);
> +   const bool matchable = traits_type::eq_int_type(chk_delim, __delim);
> +   if (__builtin_expect(!matchable, 0))
> + return ignore(__n);
> +   // Now we know that __delim is a valid char_type value, so it's safe
> +   // for the code below to use traits_type::find to search for it.
> +  }
>
>_M_gcount = 0;
>sentry __cerb(*this, true);
> diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc 
> b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
> new file mode 100644
> index 000..96737485b83
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/93672.cc
> @@ -0,0 +1,101 @@
> +// { dg-do run }
> +
> +#include 
> +#include 
> +#include 
> +
> +void
> +test_pr93672() // std::basic_istream::ignore hangs if delim MSB is set
> +{
> +  std::istringstream in(".\xfc..\xfd...\xfe.");
> +
> +  // This should find '\xfd' even on platforms where char is signed,
> +  // because the delimiter is correctly converted to the stream's int_type.
> +  in.ignore(100, std

[r14-9969 Regression] FAIL: gcc.dg/vect/vect-early-break_124-pr114403.c -flto -ffat-lto-objects execution test on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

85002f8085c25bb3e74ab013581a74e7c7ae006b is the first bad commit
commit 85002f8085c25bb3e74ab013581a74e7c7ae006b
Author: Tamar Christina 
Date:   Mon Apr 15 12:06:21 2024 +0100

middle-end: adjust loop upper bounds when peeling for gaps and early break 
[PR114403].

caused

FAIL: gcc.dg/vect/vect-early-break_124-pr114403.c execution test
FAIL: gcc.dg/vect/vect-early-break_124-pr114403.c -flto -ffat-lto-objects 
execution test

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-9969/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-early-break_124-pr114403.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-early-break_124-pr114403.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)

Re: [PATCH] gotools: Workaround non-reproduceability of automake

[Eric Gallager]

On Mon, Apr 15, 2024 at 8:43 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The regen bot recently flagged a difference in gotools/Makefile.in.
> Trying it locally, it seems pretty random
> for i in `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH 
> automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo; for i in 
> `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH setarch 
> x86_64 -R automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo;
> 14 14 14 0 0 0 14 0 14 0 14 14 14 14 0 14 14 0 0 0
> 14 0 14 0 0 14 14 14 0 14 14 0 0 14 14 14 0 0 0 14
> The 14 line git diff is
> diff --git a/gotools/Makefile.in b/gotools/Makefile.in
> index 36c2ec2abd3..f40883c39be 100644
> --- a/gotools/Makefile.in
> +++ b/gotools/Makefile.in
> @@ -704,8 +704,8 @@ distclean-generic:
>  maintainer-clean-generic:
> @echo "This command is intended for maintainers to use"
> @echo "it deletes files that may require special tools to rebuild."
> -@NATIVE_FALSE@install-exec-local:
>  @NATIVE_FALSE@uninstall-local:
> +@NATIVE_FALSE@install-exec-local:
>  clean: clean-am
>
>  clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
> so whether it is
> @NATIVE_FALSE@install-exec-local:
> @NATIVE_FALSE@uninstall-local:
> or
> @NATIVE_FALSE@uninstall-local:
> @NATIVE_FALSE@install-exec-local:
> depends on some hash table traversal or what.
>
> I'm not familiar with automake/m4 enough to debug that, so I'm
> instead offering a workaround, with this patch the order is deterministic.

Is there a bug open with automake upstream for this?

>
> 2024-04-15  Jakub Jelinek  
>
> * Makefile.am (install-exec-local, uninstall-local): Add goals
> on the else branch of if NATIVE to ensure reproducibility.
> * Makefile.in: Regenerate.
>
> --- gotools/Makefile.am.jj  2023-11-04 09:02:35.802995614 +0100
> +++ gotools/Makefile.am 2024-04-15 14:30:03.647171636 +0200
> @@ -366,5 +366,7 @@ else
>  # only do this if such a compiler is available.  We also need to get
>  # the right values for GOARCH and GOOS in the default build context in
>  # the go/build package.  Figure this out later.
> +install-exec-local:
> +uninstall-local:
>
>  endif
> --- gotools/Makefile.in.jj  2023-11-03 17:08:46.000439645 +0100
> +++ gotools/Makefile.in 2024-04-15 14:31:32.270040117 +0200
> @@ -704,8 +704,6 @@ distclean-generic:
>  maintainer-clean-generic:
> @echo "This command is intended for maintainers to use"
> @echo "it deletes files that may require special tools to rebuild."
> -@NATIVE_FALSE@install-exec-local:
> -@NATIVE_FALSE@uninstall-local:
>  clean: clean-am
>
>  clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
> @@ -1035,6 +1033,8 @@ mostlyclean-local:
>  # only do this if such a compiler is available.  We also need to get
>  # the right values for GOARCH and GOOS in the default build context in
>  # the go/build package.  Figure this out later.
> +@NATIVE_FALSE@install-exec-local:
> +@NATIVE_FALSE@uninstall-local:
>
>  # Tell versions [3.59,3.63) of GNU make to not export all variables.
>  # Otherwise a system limit (for SysV at least) may be exceeded.
>
> Jakub
>

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature, extension}

[Eric Gallager]

On Mon, Apr 15, 2024 at 6:14 AM Alex Coplan  wrote:
>
> On 04/04/2024 11:00, Alex Coplan wrote:
> > Hi,
> >
> > This adds a note to the GCC 14 release notes mentioning support for
> > __has_{feature,extension} (PR60512).
> >
> > OK to commit?
>
> Ping.  Is this changes.html patch OK?  I guess it needs a review from C++
> maintainers since it adds to the C++ section.
>

I think it's ok, but then again I can't approve; maybe try the docs
maintainers (i.e. Gerald and/or Sandra) if you don't hear back from
the C++ ones?

> >
> > Thanks,
> > Alex
>
> > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > index 9fd224c1..facead8d 100644
> > --- a/htdocs/gcc-14/changes.html
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -242,6 +242,12 @@ a work-in-progress.
> >constinit and optimized dynamic initialization
> >  
> >
> > +  The Clang language extensions __has_feature and
> > +__has_extension have been implemented in GCC.  These
> > +are available from C, C++, and Objective-C(++).
> > +This is primarily intended to aid the portability of code written
> > +against Clang.
> > +  
> >  
> >
> >  Runtime Library (libstdc++)
>

Re: [PATCH] gotools: Workaround non-reproduceability of automake

[Jakub Jelinek]

On Mon, Apr 15, 2024 at 04:20:16PM -0400, Eric Gallager wrote:
> > I'm not familiar with automake/m4 enough to debug that, so I'm
> > instead offering a workaround, with this patch the order is deterministic.
> 
> Is there a bug open with automake upstream for this?

No, feel free to file it.

Jakub

[PATCH] [contrib] validate_failures.py: fix python 3.12 escape sequence warnings

[Gabi Falk]

The warnings:
contrib/testsuite-management/validate_failures.py:65: SyntaxWarning: invalid 
escape sequence '\s'
  _VALID_TEST_RESULTS_REX = re.compile('(%s):\s*(\S+)\s*(.*)'
contrib/testsuite-management/validate_failures.py:77: SyntaxWarning: invalid 
escape sequence '\.'
  _EXP_LINE_REX = re.compile('^Running (?:.*:)?(.*) \.\.\.\n')

contrib/ChangeLog:
* testsuite-management/validate_failures.py: Change re.compile()
function arguments to Python raw strings.

Link: https://docs.python.org/dev/whatsnew/3.12.html#other-language-changes
Link: https://github.com/python/cpython/issues/98401
Signed-off-by: Gabi Falk 
---
 contrib/testsuite-management/validate_failures.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/contrib/testsuite-management/validate_failures.py 
b/contrib/testsuite-management/validate_failures.py
index f81ac4f135d2..e5188bbf105c 100755
--- a/contrib/testsuite-management/validate_failures.py
+++ b/contrib/testsuite-management/validate_failures.py
@@ -62,7 +62,7 @@ import sys

 _VALID_TEST_RESULTS = [ 'FAIL', 'UNRESOLVED', 'XPASS', 'ERROR' ]
 # :  

[PATCH] Document that vector_size works with typedefs [PR92880]

[Andrew Pinski]

This just adds a clause to make it more obvious that the vector_size
attribute extension works with typedefs.
Note this whole section needs a rewrite to be a similar format as other
extensions. But that is for another day.

OK?


gcc/ChangeLog:

PR c/92880
* doc/extend.texi (Using Vector Instructions): Add that
the base_types could be a typedef of them.

Signed-off-by: Andrew Pinski 
---
 gcc/doc/extend.texi | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7b..e290265d68d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12901,12 +12901,13 @@ typedef int v4si __attribute__ ((vector_size (16)));
 @end smallexample
 
 @noindent
-The @code{int} type specifies the @dfn{base type}, while the attribute 
specifies
-the vector size for the variable, measured in bytes.  For example, the
-declaration above causes the compiler to set the mode for the @code{v4si}
-type to be 16 bytes wide and divided into @code{int} sized units.  For
-a 32-bit @code{int} this means a vector of 4 units of 4 bytes, and the
-corresponding mode of @code{foo} is @acronym{V4SI}.
+The @code{int} type specifies the @dfn{base type} (which can be a
+@code{typedef}), while the attribute specifies the vector size for the
+variable, measured in bytes. For example, the declaration above causes
+the compiler to set the mode for the @code{v4si} type to be 16 bytes wide
+and divided into @code{int} sized units.  For a 32-bit @code{int} this
+means a vector of 4 units of 4 bytes, and the corresponding mode of
+@code{foo} is @acronym{V4SI}.
 
 The @code{vector_size} attribute is only applicable to integral and
 floating scalars, although arrays, pointers, and function return values
-- 
2.43.0

Re: Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

[Fei Gao]

On 2024-04-15 21:04  Jeff Law  wrote:
>
>
>
>On 4/15/24 6:58 AM, Kito Cheng wrote:
>> It's simple enough, so LGTM for trunk :)
>We're already doing this internally.  I just hadn't submitted it due to
>being deep into stage4.
>
>Jeff 

Hi Jeff

Would you like me to commit it now or leave it to you with your bunch of 
optimizations in Zicond?

BR
Fei

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

[Jeff Law]

On 4/15/24 7:27 PM, Fei Gao wrote:

On 2024-04-15 21:04  Jeff Law  wrote:




On 4/15/24 6:58 AM, Kito Cheng wrote:

It's simple enough, so LGTM for trunk :)

We're already doing this internally.  I just hadn't submitted it due to
being deep into stage4.

Jeff


Hi Jeff

Would you like me to commit it now or leave it to you with your bunch of 
optimizations in Zicond?

Go ahead and commit it.  It's extremely low risk.

jeff

Re: [pushed][PATCH] LoongArch: Add indexes for some compilation options.

[Lulu Cheng]

Pushed to r14-9984.

在 2024/4/9 下午4:19, Lulu Cheng 写道:

gcc/ChangeLog:

* config/loongarch/loongarch.opt.urls: Regenerate.
* config/mn10300/mn10300.opt.urls: Likewise.
* config/msp430/msp430.opt.urls: Likewise.
* config/nds32/nds32-elf.opt.urls: Likewise.
* config/nds32/nds32-linux.opt.urls: Likewise.
* config/nds32/nds32.opt.urls: Likewise.
* config/pru/pru.opt.urls: Likewise.
* config/riscv/riscv.opt.urls: Likewise.
* config/rx/rx.opt.urls: Likewise.
* config/sh/sh.opt.urls: Likewise.
* config/sparc/sparc.opt.urls: Likewise.
* doc/invoke.texi: Add indexes for some compilation options.
---
  gcc/config/loongarch/loongarch.opt.urls | 9 +++--
  gcc/config/mn10300/mn10300.opt.urls | 2 +-
  gcc/config/msp430/msp430.opt.urls   | 2 +-
  gcc/config/nds32/nds32-elf.opt.urls | 2 +-
  gcc/config/nds32/nds32-linux.opt.urls   | 2 +-
  gcc/config/nds32/nds32.opt.urls | 2 +-
  gcc/config/pru/pru.opt.urls | 2 +-
  gcc/config/riscv/riscv.opt.urls | 2 +-
  gcc/config/rx/rx.opt.urls   | 2 +-
  gcc/config/sh/sh.opt.urls   | 2 +-
  gcc/config/sparc/sparc.opt.urls | 2 +-
  gcc/doc/invoke.texi | 7 ++-
  12 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.opt.urls 
b/gcc/config/loongarch/loongarch.opt.urls
index 88f0bb0f96f..9ed5d7b5596 100644
--- a/gcc/config/loongarch/loongarch.opt.urls
+++ b/gcc/config/loongarch/loongarch.opt.urls
@@ -57,12 +57,17 @@ UrlSuffix(gcc/LoongArch-Options.html#index-mrecip)
  mrecip
  UrlSuffix(gcc/LoongArch-Options.html#index-mrecip)
  
-; skipping UrlSuffix for 'mcmodel=' due to finding no URLs

+mcmodel=
+UrlSuffix(gcc/LoongArch-Options.html#index-mcmodel)
  
  mdirect-extern-access

  UrlSuffix(gcc/LoongArch-Options.html#index-mdirect-extern-access)
  
-; skipping UrlSuffix for 'mrelax' due to finding no URLs

+mrelax
+UrlSuffix(gcc/LoongArch-Options.html#index-mrelax-2)
+
+mpass-mrelax-to-as
+UrlSuffix(gcc/LoongArch-Options.html#index-mpass-mrelax-to-as)
  
  mtls-dialect=

  UrlSuffix(gcc/LoongArch-Options.html#index-mtls-dialect-1)
diff --git a/gcc/config/mn10300/mn10300.opt.urls 
b/gcc/config/mn10300/mn10300.opt.urls
index 396ca4aa2e6..d0d1cce53a0 100644
--- a/gcc/config/mn10300/mn10300.opt.urls
+++ b/gcc/config/mn10300/mn10300.opt.urls
@@ -19,7 +19,7 @@ mno-crt0
  UrlSuffix(gcc/MN10300-Options.html#index-mno-crt0)
  
  mrelax

-UrlSuffix(gcc/MN10300-Options.html#index-mrelax-2)
+UrlSuffix(gcc/MN10300-Options.html#index-mrelax-3)
  
  mreturn-pointer-on-d0

  UrlSuffix(gcc/MN10300-Options.html#index-mreturn-pointer-on-d0)
diff --git a/gcc/config/msp430/msp430.opt.urls 
b/gcc/config/msp430/msp430.opt.urls
index 420c1c50f13..b8b8f9ce184 100644
--- a/gcc/config/msp430/msp430.opt.urls
+++ b/gcc/config/msp430/msp430.opt.urls
@@ -28,7 +28,7 @@ msmall
  UrlSuffix(gcc/MSP430-Options.html#index-msmall)
  
  mrelax

-UrlSuffix(gcc/MSP430-Options.html#index-mrelax-3)
+UrlSuffix(gcc/MSP430-Options.html#index-mrelax-4)
  
  minrt

  UrlSuffix(gcc/MSP430-Options.html#index-minrt)
diff --git a/gcc/config/nds32/nds32-elf.opt.urls 
b/gcc/config/nds32/nds32-elf.opt.urls
index 5399afba7d3..3ae1efe7312 100644
--- a/gcc/config/nds32/nds32-elf.opt.urls
+++ b/gcc/config/nds32/nds32-elf.opt.urls
@@ -1,5 +1,5 @@
  ; Autogenerated by regenerate-opt-urls.py from gcc/config/nds32/nds32-elf.opt 
and generated HTML
  
  mcmodel=

-UrlSuffix(gcc/NDS32-Options.html#index-mcmodel)
+UrlSuffix(gcc/NDS32-Options.html#index-mcmodel-1)
  
diff --git a/gcc/config/nds32/nds32-linux.opt.urls b/gcc/config/nds32/nds32-linux.opt.urls

index 27d39f04ad9..ac589ccd472 100644
--- a/gcc/config/nds32/nds32-linux.opt.urls
+++ b/gcc/config/nds32/nds32-linux.opt.urls
@@ -1,5 +1,5 @@
  ; Autogenerated by regenerate-opt-urls.py from 
gcc/config/nds32/nds32-linux.opt and generated HTML
  
  mcmodel=

-UrlSuffix(gcc/NDS32-Options.html#index-mcmodel)
+UrlSuffix(gcc/NDS32-Options.html#index-mcmodel-1)
  
diff --git a/gcc/config/nds32/nds32.opt.urls b/gcc/config/nds32/nds32.opt.urls

index e34512d69ba..44fa0696b95 100644
--- a/gcc/config/nds32/nds32.opt.urls
+++ b/gcc/config/nds32/nds32.opt.urls
@@ -51,7 +51,7 @@ mctor-dtor
  UrlSuffix(gcc/NDS32-Options.html#index-mctor-dtor)
  
  mrelax

-UrlSuffix(gcc/NDS32-Options.html#index-mrelax-4)
+UrlSuffix(gcc/NDS32-Options.html#index-mrelax-5)
  
  ; skipping UrlSuffix for 'munaligned-access' due to finding no URLs
  
diff --git a/gcc/config/pru/pru.opt.urls b/gcc/config/pru/pru.opt.urls

index 1f8a26a0db5..c87affb112b 100644
--- a/gcc/config/pru/pru.opt.urls
+++ b/gcc/config/pru/pru.opt.urls
@@ -7,7 +7,7 @@ mmcu=
  UrlSuffix(gcc/PRU-Options.html#index-mmcu-2)
  
  mno-relax

-UrlSuffix(gcc/PRU-Options.html#index-mno-relax)
+UrlSuffix(gcc/PRU-Options.html#index-mno-relax-1)
  
  mloop

  UrlSuffix(gcc/PRU-Options.html#index-mloop)
diff --git a/gcc/config/riscv/riscv.op

[testsuite] [aarch64] Require fpic effective target

[Alexandre Oliva]

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?

Co-authored-by: Olivier Hainque 

for  gcc/testsuite/ChangeLog

* gcc.target/aarch64/pr94201.c: Add missing
dg-require-effective-target fpic.
* gcc.target/aarch64/pr103085.c: Likewise.

---
 gcc/testsuite/gcc.target/aarch64/pr103085.c |1 +
 gcc/testsuite/gcc.target/aarch64/pr94201.c  |1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.target/aarch64/pr103085.c 
b/gcc/testsuite/gcc.target/aarch64/pr103085.c
index dbc9c15b71f22..347280ed42b2d 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr103085.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr103085.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-protector-strong -fPIC" } */
+/* { dg-require-effective-target fpic } */
 
 void g(int*);
 void
diff --git a/gcc/testsuite/gcc.target/aarch64/pr94201.c 
b/gcc/testsuite/gcc.target/aarch64/pr94201.c
index 691761691868a..3b9b79059e02b 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr94201.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr94201.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-mcmodel=tiny -mabi=ilp32 -fPIC" } */
+/* { dg-require-effective-target fpic } */
 
 extern int bar (void *);
 extern long long a;

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [libstdc++] define zoneinfo_dir_override on vxworks

[Alexandre Oliva]

VxWorks fails to load kernel-mode modules with weak undefined symbols.
In RTP mode modules, that undergo final linking, weak undefined
symbols are not a problem.

This patch adds kernel-mode VxWorks multilibs to the set of targets
that don't support weak undefined symbols without special flags, in
which tzdb's zoneinfo_dir_override is given a weak definition.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  libstdc++-v3/ChangeLog

* src/c++20/tzdb.cc (__gnu_cxx::zoneinfo_dir_override): Define
on VxWorks non-RTP.
---
 libstdc++-v3/src/c++20/tzdb.cc |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 890a4c53e2d44..639d1c440ba16 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -70,8 +70,9 @@ namespace __gnu_cxx
 #else
   [[gnu::weak]] const char* zoneinfo_dir_override();
 
-#if defined(__APPLE__) || defined(__hpux__)
-  // Need a weak definition for Mach-O.
+#if defined(__APPLE__) || defined(__hpux__) \
+  || (defined(__VXWORKS__) && !defined(__RTP__))
+  // Need a weak definition for Mach-O et al.
   [[gnu::weak]] const char* zoneinfo_dir_override()
   {
 #ifdef _GLIBCXX_ZONEINFO_DIR

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t

[Alexandre Oliva]

Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
adjusted about a year ago to skip long double on some targets, because
the fastfloat library was limited to 64-bit doubles.

The same problem comes up in similar float128_t tests on
aarch64-vxworks.  This patch adjusts them similarly.

Unlike the earlier tests, that got similar treatment for
x86_64-vxworks, these haven't failed there.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  libstdc++-v3/ChangeLog

* testsuite/20_util/from_chars/8.cc: Skip float128_t testing
on aarch64-vxworks.
* testsuite/20_util/to_chars/float128-c++23.cc: Xfail run on
aarch64-vxworks.
---
 libstdc++-v3/testsuite/20_util/from_chars/8.cc |3 ++-
 .../testsuite/20_util/to_chars/float128_c++23.cc   |1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/8.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
index ee60d88c332db..a6343422c5a91 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++23 } }
 // { dg-add-options ieee }
+// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* } }
 
 #include 
 #include 
@@ -343,7 +344,7 @@ test06()
 #if defined(__STDCPP_FLOAT64_T__) && defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
   test_max_mantissa();
 #endif
-#if defined(__GLIBCXX_TYPE_INT_N_0) \
+#if defined(__GLIBCXX_TYPE_INT_N_0) && !defined SKIP_LONG_DOUBLE \
 && defined(__STDCPP_FLOAT128_T__) && 
defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
   test_max_mantissa();
 #endif
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc 
b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
index 547632817b4bb..ca00761ee7c98 100644
--- a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
+++ b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
@@ -19,6 +19,7 @@
 // { dg-require-effective-target ieee_floats }
 // { dg-require-effective-target size32plus }
 // { dg-add-options ieee }
+// { dg-xfail-run-if "from_chars limited to double-precision" { 
aarch64-*-vxworks* } }
 
 #include 
 #include 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [c++] [testsuite] adjust contracts9.C for negative addresses

[Alexandre Oliva]

The test expected the address of a literal string, converted to long
long, to yield a positive value.  That expectation doesn't necessarily
hold, and the test fails where it doesn't.

Adjust the test to use a pointer that will compare as expected.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* g++.dg/contracts/contracts9.C: Don't assume string literals
have non-negative addresses.
---
 gcc/testsuite/g++.dg/contracts/contracts9.C |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/contracts/contracts9.C 
b/gcc/testsuite/g++.dg/contracts/contracts9.C
index 09a1a6532c5a0..58b60aca32057 100644
--- a/gcc/testsuite/g++.dg/contracts/contracts9.C
+++ b/gcc/testsuite/g++.dg/contracts/contracts9.C
@@ -27,7 +27,7 @@ int main()
 {
   fun1(1, -1);
   fun1(-1, 1.0);
-  fun1(-1, "test");
+  fun1(-1, (const char *)0x1234);
 
   [[ assert: fun1(-1, -5) ]];
   [[ assert: test::fun(10, -6) ]];

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] introduce strndup effective target

[Alexandre Oliva]

A number of tests that call strndup fail on vxworks, where there's no
strndup.  Some of them already had workarounds to skip the strndup
parts of the tests on platforms that don't offer it.  I've changed
them to rely on a strndup effective target instead, and extended the
logic to other tests that were otherwise skipped entirely.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/ChangeLog

* doc/sourcebuild.texi (strndup): Add effective target.

for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (check_effective_target_strndup): New.
* gcc.dg/builtin-dynamic-object-size-0.c: Skip strndup tests
when the function is not available.
* gcc.dg/builtin-dynamic-object-size-1.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-2.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-3.c: Likewise.
* gcc.dg/builtin-dynamic-object-size-4.c: Likewise.
* gcc.dg/builtin-object-size-1.c: Likewise.
* gcc.dg/builtin-object-size-2.c: Likewise.
* gcc.dg/builtin-object-size-3.c: Likewise.
* gcc.dg/builtin-object-size-4.c: Likewise.
---
 gcc/doc/sourcebuild.texi   |3 +++
 .../gcc.dg/builtin-dynamic-object-size-0.c |   10 +-
 gcc/testsuite/gcc.dg/builtin-object-size-1.c   |7 ---
 gcc/testsuite/gcc.dg/builtin-object-size-2.c   |7 ---
 gcc/testsuite/gcc.dg/builtin-object-size-3.c   |7 ---
 gcc/testsuite/gcc.dg/builtin-object-size-4.c   |7 ---
 gcc/testsuite/lib/target-supports.exp  |   11 +++
 7 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 7c0df90e82236..8e4e59ac44c74 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2837,6 +2837,9 @@ can be included without error when @option{-mbig-endian} 
is passed.
 @item stpcpy
 Target provides @code{stpcpy} function.
 
+@item strndup
+Target provides @code{strndup} function.
+
 @item sysconf
 Target supports @code{sysconf}.
 
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c 
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
index 173e7c755f4c9..d02e37f79d95f 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
@@ -1,7 +1,7 @@
 /* { dg-do run } */
 /* { dg-options "-O2" } */
 /* { dg-require-effective-target size20plus } */
-/* { dg-skip-if "no strndup" { hppa*-*-hpux* } } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
 
 #include "builtin-object-size-common.h"
 
@@ -567,6 +567,7 @@ test_strdup (const char *in)
   return sz;
 }
 
+#ifndef SKIP_STRNDUP
 size_t
 __attribute__ ((noinline))
 test_strndup (const char *in, size_t bound)
@@ -577,6 +578,7 @@ test_strndup (const char *in, size_t bound)
   __builtin_free (res);
   return sz;
 }
+#endif
 
 size_t
 __attribute__ ((noinline))
@@ -589,6 +591,7 @@ test_strdup_min (const char *in)
   return sz;
 }
 
+#ifndef SKIP_STRNDUP
 size_t
 __attribute__ ((noinline))
 test_strndup_min (const char *in, size_t bound)
@@ -599,6 +602,7 @@ test_strndup_min (const char *in, size_t bound)
   __builtin_free (res);
   return sz;
 }
+#endif
 
 /* Other tests.  */
 
@@ -788,12 +792,16 @@ main (int argc, char **argv)
   const char *str = "hello world";
   if (test_strdup (str) != __builtin_strlen (str) + 1)
 FAIL ();
+#ifndef SKIP_STRNDUP
   if (test_strndup (str, 4) != 5)
 FAIL ();
+#endif
   if (test_strdup_min (str) != __builtin_strlen (str) + 1)
 FAIL ();
+#ifndef SKIP_STRNDUP
   if (test_strndup_min (str, 4) != 1)
 FAIL ();
+#endif
 
   DONE ();
 }
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-1.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-1.c
index 4f7d4c0b370f5..d6d13c5ef7a29 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-1.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-1.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-options "-O2 -Wno-stringop-overread" } */
 /* { dg-require-effective-target alloca } */
+/* { dg-additional-options "-DSKIP_STRNDUP" { target { ! strndup } } } */
 
 #include "builtin-object-size-common.h"
 
@@ -621,7 +622,7 @@ test10 (void)
 }
 }
 
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
 /* Tests for strdup/strndup.  */
 size_t
 __attribute__ ((noinline))
@@ -709,7 +710,7 @@ test11 (void)
 FAIL ();
   free (res);
 }
-#endif /* avr */
+#endif
 
 int
 main (void)
@@ -726,7 +727,7 @@ main (void)
   test8 ();
   test9 (1);
   test10 ();
-#if !defined(__AVR__) && !defined(__hpux__) /* avr and hpux have no strndup */
+#ifndef SKIP_STRNDUP
   test11 ();
 #endif
   DONE ();
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-2.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-2.c
index 37d3dcc6f5689..c28d72eee9bfe 100644
--- a/gcc/testsuite/g

[PATCH] [testsuite] [analyzer] avoid vxworks libc mode_t

[Alexandre Oliva]

Define macro that prevents mode_t from being defined by vxworks'
headers as well.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/analyzer/fd-4.c: Define macro to avoid mode_t on
vxworks.
---
 gcc/testsuite/gcc.dg/analyzer/fd-4.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-4.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-4.c
index 880de3d789607..d104bfdad547f 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-4.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-4.c
@@ -1,4 +1,5 @@
 /* { dg-additional-options "-D_MODE_T_DECLARED=1" { target newlib } } */
+/* { dg-additional-options "-D_DEFINED_mode_t" { target *-*-vxworks* } } */
 #if defined(_AIX) || defined(__hpux)
 #define _MODE_T
 #endif

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [analyzer] skip access-mode: O_ACCMODE on vxworks

[Alexandre Oliva]

O_ACCMODE is not defined on vxworks, and the test is meaningless and
failing without it, so skip it.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/analyzer/fd-access-mode-target-headers.c: Skip on
vxworks as well.
---
 .../analyzer/fd-access-mode-target-headers.c   |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
index b57b9fa2279c2..9fc32638a3de4 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c
@@ -1,5 +1,4 @@
-/* { dg-skip-if "" { powerpc*-*-aix* || newlib } } */
-/* { dg-skip-if "" { avr-*-* } } */
+/* { dg-skip-if "" { { powerpc*-*-aix* avr-*-* *-*-vxworks* } || newlib } } */
 
 #include 
 #include 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [analyzer] require fork where used

[Alexandre Oliva]

Mark tests that fail due to the lack of fork, as in vxworks kernel
mode, as requiring fork.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/analyzer/pipe-glibc.c: Require fork.
* gcc.dg/analyzer/pipe-manpages.c: Likewise.
---
 gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c|5 +++--
 gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c |2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c 
b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
index 60558a870b9d7..fe38ddef3959a 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
@@ -1,6 +1,7 @@
-/* Example of pipe usage from glibc manual.  */
-
 /* { dg-skip-if "" { "avr-*-*" } } */
+/* { dg-require-fork "" } */
+
+/* Example of pipe usage from glibc manual.  */
 
 #include 
 #include 
diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c 
b/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
index 6b9ae4d260281..ac5805fdba092 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pipe-manpages.c
@@ -1,3 +1,5 @@
+/* { dg-require-fork "" } */
+
 /* Example of "pipe" from release 5.13 of the Linux man-pages project.
 
 Copyright (C) 2005, 2008, Michael Kerrisk 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [vxworks] avoid mangling __STDC_VERSION_LIMITS_H__

[Alexandre Oliva]

The mangling of the macro name that guards limits.h from reinclusion
was mangling a c23-required macro as well.  Make the edit pattern
stricter.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/ChangeLog

* config/t-vxworks (vxw-glimits.h): Don't mangle c23-required
__STDC_VERSION_LIMITS_H__ define.
---
 gcc/config/t-vxworks |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/t-vxworks b/gcc/config/t-vxworks
index b89350c3c70f4..6063943e346e6 100644
--- a/gcc/config/t-vxworks
+++ b/gcc/config/t-vxworks
@@ -57,7 +57,7 @@ T_GLIMITS_H = vxw-glimits.h
 
 vxw-glimits.h: $(srcdir)/glimits.h
ID=`echo $(BASEVER_c) | sed -e 's/\./_/g'` && \
-   sed -e "s/_LIMITS_H__/_LIMITS_H__$${ID}_/" < $< > $@T
+   sed -e "s/_LIMITS_H___/_LIMITS_H__$${ID}_/" < $< > $@T
mv $@T $@
 
 # Arrange to "provide" a tailored version of stdint-gcc.h

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [analyzer] include sys/select.h if available

[Alexandre Oliva]

Test that calls select fails on vxworks because select is only
declared in sys/select.h.  Include that header if it's present.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c:
Include sys/select.h if present.
---
 .../fd-glibc-byte-stream-connection-server.c   |3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c
index fcbcc740170e6..f922a52238f90 100644
--- a/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 #include 
+#if __has_include()
+#include 
+#endif
 #include 
 #include 
 #include 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] xfail pr103798-2 in C++ on vxworks too [PR113706]

[Alexandre Oliva]

pr103798-2.c fails in C++ on targets that provide a ISO C++-compliant
declaration of memchr, because it mismatches the C-compatible builtin,
as per PR113706.  Expect the C++ test to fail on vxworks as well.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

PR testsuite/113706
* c-c++-common/pr103798-2.c: XFAIL in C++ on vxworks too.
---
 gcc/testsuite/c-c++-common/pr103798-2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/pr103798-2.c 
b/gcc/testsuite/c-c++-common/pr103798-2.c
index bc126c205e1e3..83cdfaa1660bb 100644
--- a/gcc/testsuite/c-c++-common/pr103798-2.c
+++ b/gcc/testsuite/c-c++-common/pr103798-2.c
@@ -28,4 +28,4 @@ main ()
 }
 
 /* See PR c++/113706 for the xfail.  */
-/* { dg-final { scan-assembler-not "memchr" { xfail { c++ && *-*-solaris2* } } 
} } */
+/* { dg-final { scan-assembler-not "memchr" { xfail { c++ && { *-*-solaris2* 
*-*-vxworks* } } } } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [libstdc++] introduce --disable-compat-libstdcxx-abi

[Alexandre Oliva]

A number of libstdc++ tests that implicitly instantiate
__to_chars_i and also link floating_to_chars.o in
fail on vxworks kernel mode.  The platform doesn't support undefweak
symbols (the kernel module loader fails to load modules containing
them), and because creating such modules doesn't involve final
linking, only -r linking.  The vague-linkage weak defs with abi-v2
mangling that get discarded from floating_to_chars.o because the same
comdat section is present in the main executable.  But since the
alternate mangling is not defined in the main executable, the weak
definition decays to a weak undefined symbol in the partially-linked
kernel module, and then the kernel module loader barfs.

Since our vxworks toolchains have little use for the compat ABI
symbols, I thought we could work around this problem by getting rid of
them.  Absent a configure option to control that, I added one.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?

PS: for an alternate path to avoid this problem, see also
https://sourceware.org/pipermail/binutils/2024-April/133602.html
https://sourceware.org/pipermail/binutils/2024-April/133410.html 


for  libstdc++-v3/ChangeLog

* acinclude.m4 (GLIBCXX_EXPORT_FLAGS): Split -Wabi=2...
(GLIBCXX_ENABLE_WABI): ... here.  Control it with newly added
--disable-compat-libstdcxx-abi.
* configure: Rebuilt.
* doc/html/manual/configure.html: Document it.
---
 libstdc++-v3/acinclude.m4   |   26 ++
 libstdc++-v3/configure  |   49 ++-
 libstdc++-v3/doc/html/manual/configure.html |2 +
 3 files changed, 67 insertions(+), 10 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 51a08bcc8b1d0..4ef5d5e98c2be 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -707,10 +707,34 @@ AC_DEFUN([GLIBCXX_EXPORT_FLAGS], [
   # OPTIMIZE_CXXFLAGS = -O3 -fstrict-aliasing -fvtable-gc
   AC_SUBST(OPTIMIZE_CXXFLAGS)
 
-  WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2"
+  WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual"
   AC_SUBST(WARN_FLAGS)
+
+  GLIBCXX_ENABLE_WABI
 ])
 
+dnl
+dnl Enable -Wabi=2 if not overridden by --disable-compat-libstdcxx-abi.
+dnl
+AC_DEFUN([GLIBCXX_ENABLE_WABI], [
+  # Default.
+  WARN_FLAGS_WABI=\ -Wabi=2
+  AC_MSG_CHECKING([for --disable-compat-libstdcxx-abi])
+  AC_ARG_ENABLE([compat-libstdcxx-abi],
+AC_HELP_STRING([--disable-compat-libstdcxx-abi],
+  [Disable backward-compatibility ABI symbols)]),
+[case "$enableval" in
+  yes) AC_MSG_RESULT(enabled$WARN_FLAGS_WABI) ;;
+  no)  WARN_FLAGS_WABI=
+  AC_MSG_RESULT(disabled) ;;
+  *)   AC_MSG_RESULT(unsupported)
+  AC_MSG_ERROR([Unsupported argument to enable/disable compat 
libstdc++ abi]);;
+ esac], [
+  AC_MSG_RESULT(defaulting to enabled$WARN_FLAGS_WABI)
+ ])
+
+  WARN_FLAGS="$WARN_FLAGS$WARN_FLAGS_WABI"
+])
 
 dnl
 dnl All installation directory information is determined here.
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 21abaeb077881..8066397b58c2e 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -973,6 +973,7 @@ enable_cet
 with_gxx_include_dir
 enable_version_specific_runtime_libs
 with_toolexeclibdir
+enable_compat_libstdcxx_abi
 with_gcc_major_version_only
 '
   ac_precious_vars='build_alias
@@ -1689,6 +1690,8 @@ Optional Features:
   --enable-version-specific-runtime-libs
   Specify that runtime libraries should be installed
   in a compiler-specific directory
+  --disable-compat-libstdcxx-abi
+  Disable backward-compatibility ABI symbols)
 
 Optional Packages:
   --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -12280,7 +12283,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12283 "configure"
+#line 12286 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12386,7 +12389,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12389 "configure"
+#line 12392 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16182,7 +16185,7 @@ $as_echo "$glibcxx_cv_atomic_long_long" >&6; }
   # Fake what AC_TRY_COMPILE does.
 
 cat > conftest.$ac_ext << EOF
-#line 16185 "configure"
+#line 16188 "configure"
 int main()
 {
   typedef bool atomic_type;
@@ -16217,7 +16220,7 @@ $as_echo "$glibcxx_cv_atomic_bool" >&6; }
 rm -f conftest*
 
 cat > conftest.$ac_ext << EOF
-#line 16220 "configure"
+#line 16223 "configure"
 int main()
 {
   typedef short atomic_type;
@@ -16252,7 +16255,7 @@ $as_echo "$glibcxx_cv_atomic_short" >&6; }
 rm -f conftest*
 
 cat > conftest.$ac_ext << EOF
-#line 16255 "configure"
+#line 16258 "c

[PATCH] [testsuite] [i386] require fpic for pr111497.C

[Alexandre Oliva]

Fix another test that uses -fPIC without requiring fpic support.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?

PS: This is neither the first nor the last such patch.  Maybe the test
harness could detect -fPIC et al in compile options and react
intelligently to them, whether by warning if dg-require-effective-target
fpic is missing, or adding it implicitly.  We could have more such
smarts in the testsuite machinery.  WDYT?


for  gcc/testsuite/ChangeLog

* g++.target/i386/pr111497.C: Require fpic support.
---
 gcc/testsuite/g++.target/i386/pr111497.C |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.target/i386/pr111497.C 
b/gcc/testsuite/g++.target/i386/pr111497.C
index a645bb95907ee..30e2e0409ad0e 100644
--- a/gcc/testsuite/g++.target/i386/pr111497.C
+++ b/gcc/testsuite/g++.target/i386/pr111497.C
@@ -1,5 +1,6 @@
 // { dg-do compile { target ia32 } }
 // { dg-options "-march=i686 -mtune=generic -fPIC -O2 -g" }
+// { dg-require-effective-target fpic }
 
 class A;
 struct B { const char *b1; int b2; };

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [arm] require arm_v8_1m_main for pacbti tests

[Alexandre Oliva]

arm pac and bti tests that use -march=armv8.1-m.main get an implicit
-mthumb, that is incompatible with vxworks kernel mode.  Declaring the
requirement for a 8.1-m.main-compatible toolchain is enough to avoid
those fails, because the toolchain feature test fails in kernel mode.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* g++.target/arm/pac-1.C: Require arm_arch_v8_1m_main.
* gcc.target/arm/acle/pacbti-m-predef-11.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-12.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise.
* gcc.target/arm/bti-1.c: Likewise.
* gcc.target/arm/bti-2.c: Likewise.
---
 gcc/testsuite/g++.target/arm/pac-1.C   |1 +
 .../gcc.target/arm/acle/pacbti-m-predef-11.c   |1 +
 .../gcc.target/arm/acle/pacbti-m-predef-12.c   |1 +
 .../gcc.target/arm/acle/pacbti-m-predef-7.c|1 +
 gcc/testsuite/gcc.target/arm/bti-1.c   |1 +
 gcc/testsuite/gcc.target/arm/bti-2.c   |1 +
 6 files changed, 6 insertions(+)

diff --git a/gcc/testsuite/g++.target/arm/pac-1.C 
b/gcc/testsuite/g++.target/arm/pac-1.C
index f671a27b048c6..f48ad6cc5cb65 100644
--- a/gcc/testsuite/g++.target/arm/pac-1.C
+++ b/gcc/testsuite/g++.target/arm/pac-1.C
@@ -2,6 +2,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-options "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
-mthumb -mfloat-abi=hard -g -O0" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
 
 __attribute__((noinline)) void
 fn1 (int a, int b, int c)
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
index 6a5ae92c567f3..dba4f491cfea7 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" "-mfloat-abi=*" } } */
 /* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
 
 #if (__ARM_FEATURE_BTI != 1)
 #error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined to 1."
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
index db40b17c3b030..308a41eb4ba4c 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-12.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-options "-march=armv8-m.main+fp -mfloat-abi=softfp" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
 
 #if defined (__ARM_FEATURE_BTI)
 #error "Feature test macro __ARM_FEATURE_BTI should not be defined."
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
index 1b25907635e24..10836a84bde56 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-additional-options "-march=armv8.1-m.main+pacbti+fp --save-temps 
-mfloat-abi=hard" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
 
 #if defined (__ARM_FEATURE_BTI_DEFAULT)
 #error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be undefined."
diff --git a/gcc/testsuite/gcc.target/arm/bti-1.c 
b/gcc/testsuite/gcc.target/arm/bti-1.c
index 79dd8010d2dab..34655387b55f5 100644
--- a/gcc/testsuite/gcc.target/arm/bti-1.c
+++ b/gcc/testsuite/gcc.target/arm/bti-1.c
@@ -2,6 +2,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
 
 int
 main (void)
diff --git a/gcc/testsuite/gcc.target/arm/bti-2.c 
b/gcc/testsuite/gcc.target/arm/bti-2.c
index 33910563849a4..3284aba3020cc 100644
--- a/gcc/testsuite/gcc.target/arm/bti-2.c
+++ b/gcc/testsuite/gcc.target/arm/bti-2.c
@@ -3,6 +3,7 @@
 /* { dg-options "-Os" } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" 
"-mcpu=*" } } */
 /* { dg-options "-march=armv8.1-m.main -mthumb -mfloat-abi=softfp 
-mbranch-protection=bti --save-temps" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
 
 extern int f1 (void);
 extern int f2 (void);

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Softwar

[PATCH] [libstdc++] [testsuite] disable SRA for compare_exchange_padding

[Alexandre Oliva]

On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
padding bits in the tests are not what we might expect from full-word
struct copies.

I tried adding a function to perform bitwise copying, but even taking
the as.load() argument by const&, we'd still construct a temporary
with SRAed field-wise copying.  Unable to find another way to ensure
we wouldn't get a temporary, I went for disabling SRA.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  libstdc++-v3/ChangeLog

* testsuite/29_atomics/atomic/compare_exchange_padding.cc:
Disable SRA.
---
 .../29_atomics/atomic/compare_exchange_padding.cc  |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
index 2f18d426e7f7e..a6081968ca869 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
@@ -1,6 +1,7 @@
 // { dg-do run { target c++20 } }
 // { dg-require-atomic-cmpxchg-word "" }
 // { dg-add-options libatomic }
+// { dg-additional-options "-fno-tree-sra" }
 
 #include 
 #include 
@@ -26,10 +27,10 @@ main ()
   s.s = 42;
 
   std::atomic as{ s };
-  auto ts = as.load();
+  auto ts = as.load(); // SRA might prevent copying of padding bits here.
   VERIFY( !compare_struct(s, ts) ); // padding cleared on construction
   as.exchange(s);
-  auto es = as.load();
+  auto es = as.load(); // SRA might prevent copying of padding bits here.
   VERIFY( compare_struct(ts, es) ); // padding cleared on exchange
 
   S n;

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [arm] accept empty init for bfloat16

[Alexandre Oliva]

Complete r13-2205, adjusting an arm-specific test that expects a
no-longer-issued error at an empty initializer.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/arm/bfloat16_scalar_typecheck.c: Accept C23
empty initializers.
---
 .../gcc.target/arm/bfloat16_scalar_typecheck.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c 
b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
index 8c80c55bc9f4c..04ede93bda152 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_scalar_typecheck.c
@@ -42,7 +42,7 @@ bfloat16_t footest (bfloat16_t scalar0)
   short initi_1_4 = glob_bfloat; /* { dg-error {invalid conversion from type 
'bfloat16_t'} } */
   double initi_1_5 = glob_bfloat; /* { dg-error {invalid conversion from type 
'bfloat16_t'} } */
 
-  bfloat16_t scalar2_1 = {}; /* { dg-error {empty scalar initializer} } */
+  bfloat16_t scalar2_1 = {};
   bfloat16_t scalar2_2 = { glob_bfloat };
   bfloat16_t scalar2_3 = { 0 }; /* { dg-error {invalid conversion to type 
'bfloat16_t'} } */
   bfloat16_t scalar2_4 = { 0.1 }; /* { dg-error {invalid conversion to type 
'bfloat16_t'} } */
@@ -94,7 +94,7 @@ bfloat16_t footest (bfloat16_t scalar0)
 
   /* Compound literals.  */
 
-  (bfloat16_t) {}; /* { dg-error {empty scalar initializer} } */
+  (bfloat16_t) {};
   (bfloat16_t) { glob_bfloat };
   (bfloat16_t) { 0 }; /* { dg-error {invalid conversion to type 'bfloat16_t'} 
} */
   (bfloat16_t) { 0.1 }; /* { dg-error {invalid conversion to type 
'bfloat16_t'} } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [i386] work around fails with --enable-frame-pointer

[Alexandre Oliva]

A few x86 tests get unexpected insn counts if the toolchain is
configured with --enable-frame-pointer.  Add explicit
-fomit-frame-pointer so that the expected insn sequences are output.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/i386/pr107261.c: Add -fomit-frame-pointer.
* gcc.target/i386/pr69482-1.c: Likewise.
* gcc.target/i386/pr69482-2.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/pr107261.c  |2 +-
 gcc/testsuite/gcc.target/i386/pr69482-1.c |2 +-
 gcc/testsuite/gcc.target/i386/pr69482-2.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr107261.c 
b/gcc/testsuite/gcc.target/i386/pr107261.c
index eb1d232fbfc4b..b422af9cbf9a2 100644
--- a/gcc/testsuite/gcc.target/i386/pr107261.c
+++ b/gcc/testsuite/gcc.target/i386/pr107261.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -msse2" } */
+/* { dg-options "-O2 -msse2 -fomit-frame-pointer" } */
 
 typedef __bf16 v4bf __attribute__ ((vector_size (8)));
 typedef __bf16 v2bf __attribute__ ((vector_size (4)));
diff --git a/gcc/testsuite/gcc.target/i386/pr69482-1.c 
b/gcc/testsuite/gcc.target/i386/pr69482-1.c
index 99bb6ad5a377b..7ef0e71b17c8e 100644
--- a/gcc/testsuite/gcc.target/i386/pr69482-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr69482-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O3 -fno-stack-protector" } */
+/* { dg-options "-O3 -fno-stack-protector -fomit-frame-pointer" } */
 
 static inline void memset_s(void* s, int n) {
   volatile unsigned char * p = s;
diff --git a/gcc/testsuite/gcc.target/i386/pr69482-2.c 
b/gcc/testsuite/gcc.target/i386/pr69482-2.c
index 58e89a7933364..6aabe4fb39399 100644
--- a/gcc/testsuite/gcc.target/i386/pr69482-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr69482-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fomit-frame-pointer" } */
 
 void bar ()
 {

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [i386] add -msse2 to tests that require it

[Alexandre Oliva]

Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
declared.

Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/i386/bf16_short_warn.c: Add -msse2.
---
 gcc/testsuite/gcc.target/i386/bf16_short_warn.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/i386/bf16_short_warn.c 
b/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
index 3e47a815200c2..2e05624bc26f6 100644
--- a/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
+++ b/gcc/testsuite/gcc.target/i386/bf16_short_warn.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -msse2" } */
 
 #include
 typedef struct {

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] [strub] improve handling of indirected volatile parms [PR112938]

[Alexandre Oliva]

On Mar 11, 2024, Richard Biener  wrote:

> On Sat, Mar 9, 2024 at 10:10 AM Alexandre Oliva  wrote:
>> 
>> 
>> The earlier patch for PR112938 arranged for volatile parms to be made
>> indirect in internal strub wrapped bodies.
>> 
>> The first problem that remained, more evident, was that the indirected
>> parameter remained volatile, despite the indirection, but it wasn't
>> regimplified, so indirecting it was malformed gimple.
>> 
>> Regimplifying turned out not to be needed.  The best course of action
>> was to drop the volatility from the by-reference parm, that was being
>> unexpectedly inherited from the original volatile parm.
>> 
>> That exposed another problem: the dereferences would then lose their
>> volatile status, so we had to bring volatile back to them.
>> 
>> Regstrapped on x86_64-linux-gnu.  Ok to install?

> OK

Thanks, sorry, I dropped the ball on this one.

I'm going to put it in momentarily.  It had been approved for gcc 14,
before it branched off; should I install it there as well?

>> 
>> for  gcc/ChangeLog
>> 
>> PR middle-end/112938
>> * ipa-strub.cc (pass_ipa_strub::execute): Drop volatility from
>> indirected parm.
>> (maybe_make_indirect): Restore volatility in dereferences.
>> 
>> for  gcc/testsuite/ChangeLog
>> 
>> PR middle-end/112938
>> * g++.dg/strub-internal-pr112938.cc: New.


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] [tree-prof] skip if errors were seen [PR113681]

[Alexandre Oliva]

On Mar 29, 2024, Alexandre Oliva  wrote:

> On Mar 22, 2024, Jeff Law  wrote:
>> On 3/9/24 2:11 AM, Alexandre Oliva wrote:
>>> ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
>>> don't reach that state and ICE if e.g. ipa-strub passes report errors.
>>> Skip this pass if errors were seen.
>>> Regstrapped on x86_64-linux-gnu.  Ok to install?
>>> 
>>> for  gcc/ChangeLog
>>> PR tree-optimization/113681
>>> * tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if
>>> seen_errors.
>>> for  gcc/testsuite/ChangeLog
>>> PR tree-optimization/113681
>>> * c-c++-common/strub-pr113681.c: New.
>> So I've really never dug into strub, but this would seem to imply that
>> an error from strub is non-fatal?

> Yeah.  I believe that's no different from other passes.

> Various other passes have seen_errors guards, but ipa-prof didn't.

Specifically, pass_build_ssa_passes in passes.cc is gated with
!seen_errors(), so we skip all the passes bundled in it, and don't
advance the symtab state to IPA_SSA.  So other passes that would require
IPA_SSA need to be gated similarly.

> I suppose the insertion point for the strubm pass was one where others
> passes didn't previously issue errors, so that wasn't an issue for
> ipa-prof.  But now it is.

The patch needed adjustments to resolve conflicts with unrelated
changes.


[tree-prof] skip if errors were seen [PR113681]

ipa_tree_profile asserts that the symtab is in IPA_SSA state, but we
don't reach that state and ICE if e.g. ipa-strub passes report errors.
Skip this pass if errors were seen.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

PR tree-optimization/113681
* tree-profiling.cc (pass_ipa_tree_profile::gate): Skip if
seen_errors.

for  gcc/testsuite/ChangeLog

PR tree-optimization/113681
* c-c++-common/strub-pr113681.c: New.
---
 gcc/testsuite/c-c++-common/strub-pr113681.c |   22 ++
 gcc/tree-profile.cc |3 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/strub-pr113681.c

diff --git a/gcc/testsuite/c-c++-common/strub-pr113681.c 
b/gcc/testsuite/c-c++-common/strub-pr113681.c
new file mode 100644
index 0..3ef9017b2eb70
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/strub-pr113681.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-fstrub=relaxed -fbranch-probabilities" } */
+/* { dg-require-effective-target strub } */
+
+/* Same as torture/strub-inlineable1.c, but with -fbranch-probabilities, to
+   check that IPA tree-profiling won't ICE.  It would when we refrained from
+   running passes that would take it to IPA_SSA, but ran the pass that asserted
+   for IPA_SSA.  */
+
+inline void __attribute__ ((strub ("internal"), always_inline))
+inl_int_ali (void)
+{
+  /* No internal wrapper, so this body ALWAYS gets inlined,
+ but it cannot be called from non-strub contexts.  */
+}
+
+void
+bat (void)
+{
+  /* Not allowed, not a strub context.  */
+  inl_int_ali (); /* { dg-error "context" } */
+}
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index b87c121790c99..e4bb689cef589 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -2070,7 +2070,8 @@ pass_ipa_tree_profile::gate (function *)
  disabled.  */
   return (!in_lto_p && !flag_auto_profile
  && (flag_branch_probabilities || flag_test_coverage
- || profile_arc_flag || condition_coverage_flag));
+ || profile_arc_flag || condition_coverage_flag)
+ && !seen_error ());
 }
 
 } // anon namespace


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

docs: document early break support and pragma novector

[Tamar Christina]

docs: document early break support and pragma novector

---
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 
b4c602a523717c1d64333e44aefb60ba0ed02e7a..aceecb86f17443cfae637e90987427b98c42f6eb
 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -200,6 +200,34 @@ a work-in-progress.
 for indicating parameters that are expected to be null-terminated
 strings.
   
+  
+The vectorizer now supports vectorizing loops which contain any number of 
early breaks.
+This means loops such as:
+
+   int z[100], y[100], x[100];
+   int foo (int n)
+   {
+ int res = 0;
+ for (int i = 0; i < n; i++)
+   {
+  y[i] = x[i] * 2;
+  res += x[i] + y[i];
+
+  if (x[i] > 5)
+break;
+
+  if (z[i] > 5)
+break;
+
+   }
+ return res;
+   }
+
+can now be vectorized on a number of targets.  In this first version any
+input data sources must either have a statically known size at compile time
+or the vectorizer must be able to determine based on auxillary information
+that the accesses are aligned.
+  
 
 
 New Languages and Language specific improvements
@@ -231,6 +259,9 @@ a work-in-progress.
   previous options -std=c2x, -std=gnu2x
   and -Wc11-c2x-compat, which are deprecated but remain
   supported.
+  GCC supports a new pragma #pragma GCC novector to
+  indicate to the vectorizer not to vectorize the loop annotated with the
+  pragma.
 
 
 C++
@@ -400,6 +431,9 @@ a work-in-progress.
   warnings are enabled for C++ as well
   The DR 2237 code no longer gives an error, it emits
   a -Wtemplate-id-cdtor warning instead
+  GCC supports a new pragma #pragma GCC novector to
+  indicate to the vectorizer not to vectorize the loop annotated with the
+  pragma.
 
 
 Runtime Library (libstdc++)




-- 
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index b4c602a523717c1d64333e44aefb60ba0ed02e7a..aceecb86f17443cfae637e90987427b98c42f6eb 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -200,6 +200,34 @@ a work-in-progress.
 for indicating parameters that are expected to be null-terminated
 strings.
   
+  
+The vectorizer now supports vectorizing loops which contain any number of early breaks.
+This means loops such as:
+
+	int z[100], y[100], x[100];
+	int foo (int n)
+	{
+	  int res = 0;
+	  for (int i = 0; i < n; i++)
+	{
+	   y[i] = x[i] * 2;
+	   res += x[i] + y[i];
+
+	   if (x[i] > 5)
+		 break;
+
+	   if (z[i] > 5)
+		 break;
+
+	}
+	  return res;
+	}
+
+can now be vectorized on a number of targets.  In this first version any
+input data sources must either have a statically known size at compile time
+or the vectorizer must be able to determine based on auxillary information
+that the accesses are aligned.
+  
 
 
 New Languages and Language specific improvements
@@ -231,6 +259,9 @@ a work-in-progress.
   previous options -std=c2x, -std=gnu2x
   and -Wc11-c2x-compat, which are deprecated but remain
   supported.
+  GCC supports a new pragma #pragma GCC novector to
+  indicate to the vectorizer not to vectorize the loop annotated with the
+  pragma.
 
 
 C++
@@ -400,6 +431,9 @@ a work-in-progress.
   warnings are enabled for C++ as well
   The DR 2237 code no longer gives an error, it emits
   a -Wtemplate-id-cdtor warning instead
+  GCC supports a new pragma #pragma GCC novector to
+  indicate to the vectorizer not to vectorize the loop annotated with the
+  pragma.
 
 
 Runtime Library (libstdc++)

Re: [PATCH] [strub] improve handling of indirected volatile parms [PR112938]

[Alexandre Oliva]

On Apr 16, 2024, Alexandre Oliva  wrote:

> I'm going to put it in momentarily.  It had been approved for gcc 14,
> before it branched off; should I install it there as well?

Ermh, nevermind, I'm not sure how I got the idea that we'd already
branched, but I was absolutely sure that this was the case.  Doh! :-)

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH]middle-end: skip vectorization check on ilp32 on vect-early-break_124-pr114403.c

[Tamar Christina]

Hi all,

The testcase seems to fail vectorization on -m32 since the access pattern is
determined as too complex.  This skips the vectorization check on ilp32 systems
as I couldn't find a better proxy for being able to do strided 64-bit loads and
I suspect it would fail on all 32-bit targets.

Regtested on x86_64-pc-linux-gnu with -m32 and no issues.

Ok for master?

Thanks,
Tamar

gcc/testsuite/ChangeLog:

PR tree-optimization/114403
* gcc.dg/vect/vect-early-break_124-pr114403.c: Skip in ilp32.

---
diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c 
b/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
index 
1751296ab813fe85eaab1f58dc674bac10f6eb7a..db8e00556f116ca81c5a6558ec6ecd3b222ec93d
 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
@@ -2,11 +2,11 @@
 /* { dg-require-effective-target vect_early_break_hw } */
 /* { dg-require-effective-target vect_long_long } */
 
-/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } } */
+/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target { ! ilp32 } } 
} } */
 
 #include "tree-vect.h"
 
-typedef unsigned long PV;
+typedef unsigned long long PV;
 typedef struct _buff_t {
 int foo;
 PV Val;




-- 
diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c b/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
index 1751296ab813fe85eaab1f58dc674bac10f6eb7a..db8e00556f116ca81c5a6558ec6ecd3b222ec93d 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_124-pr114403.c
@@ -2,11 +2,11 @@
 /* { dg-require-effective-target vect_early_break_hw } */
 /* { dg-require-effective-target vect_long_long } */
 
-/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } } */
+/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" { target { ! ilp32 } } } } */
 
 #include "tree-vect.h"
 
-typedef unsigned long PV;
+typedef unsigned long long PV;
 typedef struct _buff_t {
 int foo;
 PV Val;

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

[Fei Gao]

Committed. Thanks Kito and Jeff for the reveiw. 

BR
Fei
>
>
>On 4/15/24 7:27 PM, Fei Gao wrote:
>> On 2024-04-15 21:04  Jeff Law  wrote:
>>>
>>>
>>>
>>> On 4/15/24 6:58 AM, Kito Cheng wrote:
 It's simple enough, so LGTM for trunk :)
>>> We're already doing this internally.  I just hadn't submitted it due to
>>> being deep into stage4.
>>>
>>> Jeff
>>
>> Hi Jeff
>>
>> Would you like me to commit it now or leave it to you with your bunch of 
>> optimizations in Zicond?
>Go ahead and commit it.  It's extremely low risk.
>
>jeff

Re: [PATCH] [libstdc++] define zoneinfo_dir_override on vxworks

[Jonathan Wakely]

On Tue, 16 Apr 2024, 04:17 Alexandre Oliva,  wrote:

>
> VxWorks fails to load kernel-mode modules with weak undefined symbols.
> In RTP mode modules, that undergo final linking, weak undefined
> symbols are not a problem.
>
> This patch adds kernel-mode VxWorks multilibs to the set of targets
> that don't support weak undefined symbols without special flags, in
> which tzdb's zoneinfo_dir_override is given a weak definition.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>

OK, thanks.



>
> for  libstdc++-v3/ChangeLog
>
> * src/c++20/tzdb.cc (__gnu_cxx::zoneinfo_dir_override): Define
> on VxWorks non-RTP.
> ---
>  libstdc++-v3/src/c++20/tzdb.cc |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++20/tzdb.cc
> b/libstdc++-v3/src/c++20/tzdb.cc
> index 890a4c53e2d44..639d1c440ba16 100644
> --- a/libstdc++-v3/src/c++20/tzdb.cc
> +++ b/libstdc++-v3/src/c++20/tzdb.cc
> @@ -70,8 +70,9 @@ namespace __gnu_cxx
>  #else
>[[gnu::weak]] const char* zoneinfo_dir_override();
>
> -#if defined(__APPLE__) || defined(__hpux__)
> -  // Need a weak definition for Mach-O.
> +#if defined(__APPLE__) || defined(__hpux__) \
> +  || (defined(__VXWORKS__) && !defined(__RTP__))
> +  // Need a weak definition for Mach-O et al.
>[[gnu::weak]] const char* zoneinfo_dir_override()
>{
>  #ifdef _GLIBCXX_ZONEINFO_DIR
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>

Re: [PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for float128_t

[Jonathan Wakely]

On Tue, 16 Apr 2024, 04:19 Alexandre Oliva,  wrote:

>
> Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
> adjusted about a year ago to skip long double on some targets, because
> the fastfloat library was limited to 64-bit doubles.
>
> The same problem comes up in similar float128_t tests on
> aarch64-vxworks.  This patch adjusts them similarly.
>
> Unlike the earlier tests, that got similar treatment for
> x86_64-vxworks, these haven't failed there.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>

OK, thanks



>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/20_util/from_chars/8.cc: Skip float128_t testing
> on aarch64-vxworks.
> * testsuite/20_util/to_chars/float128-c++23.cc: Xfail run on
> aarch64-vxworks.
> ---
>  libstdc++-v3/testsuite/20_util/from_chars/8.cc |3 ++-
>  .../testsuite/20_util/to_chars/float128_c++23.cc   |1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> index ee60d88c332db..a6343422c5a91 100644
> --- a/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> +++ b/libstdc++-v3/testsuite/20_util/from_chars/8.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++23 } }
>  // { dg-add-options ieee }
> +// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target
> aarch64-*-vxworks* } }
>
>  #include 
>  #include 
> @@ -343,7 +344,7 @@ test06()
>  #if defined(__STDCPP_FLOAT64_T__) &&
> defined(_GLIBCXX_DOUBLE_IS_IEEE_BINARY64)
>test_max_mantissa();
>  #endif
> -#if defined(__GLIBCXX_TYPE_INT_N_0) \
> +#if defined(__GLIBCXX_TYPE_INT_N_0) && !defined SKIP_LONG_DOUBLE \
>  && defined(__STDCPP_FLOAT128_T__) &&
> defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
>test_max_mantissa();
>  #endif
> diff --git a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> index 547632817b4bb..ca00761ee7c98 100644
> --- a/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> +++ b/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
> @@ -19,6 +19,7 @@
>  // { dg-require-effective-target ieee_floats }
>  // { dg-require-effective-target size32plus }
>  // { dg-add-options ieee }
> +// { dg-xfail-run-if "from_chars limited to double-precision" {
> aarch64-*-vxworks* } }
>
>  #include 
>  #include 
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>

Re: [PATCH] [libstdc++] [testsuite] disable SRA for compare_exchange_padding

[Jonathan Wakely]

On Tue, 16 Apr 2024 at 04:49, Alexandre Oliva  wrote:
>
>
> On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
> padding bits in the tests are not what we might expect from full-word
> struct copies.

Aha, I was wondering why this was failing on ARM!


> I tried adding a function to perform bitwise copying, but even taking
> the as.load() argument by const&, we'd still construct a temporary
> with SRAed field-wise copying.  Unable to find another way to ensure
> we wouldn't get a temporary, I went for disabling SRA.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?

Yes, thanks.

>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/29_atomics/atomic/compare_exchange_padding.cc:
> Disable SRA.
> ---
>  .../29_atomics/atomic/compare_exchange_padding.cc  |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git 
> a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc 
> b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> index 2f18d426e7f7e..a6081968ca869 100644
> --- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> +++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> @@ -1,6 +1,7 @@
>  // { dg-do run { target c++20 } }
>  // { dg-require-atomic-cmpxchg-word "" }
>  // { dg-add-options libatomic }
> +// { dg-additional-options "-fno-tree-sra" }
>
>  #include 
>  #include 
> @@ -26,10 +27,10 @@ main ()
>s.s = 42;
>
>std::atomic as{ s };
> -  auto ts = as.load();
> +  auto ts = as.load(); // SRA might prevent copying of padding bits here.
>VERIFY( !compare_struct(s, ts) ); // padding cleared on construction
>as.exchange(s);
> -  auto es = as.load();
> +  auto es = as.load(); // SRA might prevent copying of padding bits here.
>VERIFY( compare_struct(ts, es) ); // padding cleared on exchange
>
>S n;
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] [libstdc++] introduce --disable-compat-libstdcxx-abi

[Jonathan Wakely]

On Tue, 16 Apr 2024 at 04:37, Alexandre Oliva  wrote:
>
>
> A number of libstdc++ tests that implicitly instantiate
> __to_chars_i and also link floating_to_chars.o in
> fail on vxworks kernel mode.  The platform doesn't support undefweak
> symbols (the kernel module loader fails to load modules containing
> them), and because creating such modules doesn't involve final
> linking, only -r linking.  The vague-linkage weak defs with abi-v2
> mangling that get discarded from floating_to_chars.o because the same
> comdat section is present in the main executable.  But since the
> alternate mangling is not defined in the main executable, the weak
> definition decays to a weak undefined symbol in the partially-linked
> kernel module, and then the kernel module loader barfs.
>
> Since our vxworks toolchains have little use for the compat ABI
> symbols, I thought we could work around this problem by getting rid of
> them.  Absent a configure option to control that, I added one.
>
> Regstrapped on x86_64-linux-gnu.  Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2.  Ok to install?
>
> PS: for an alternate path to avoid this problem, see also
> https://sourceware.org/pipermail/binutils/2024-April/133602.html
> https://sourceware.org/pipermail/binutils/2024-April/133410.html
>
>
> for  libstdc++-v3/ChangeLog
>
> * acinclude.m4 (GLIBCXX_EXPORT_FLAGS): Split -Wabi=2...
> (GLIBCXX_ENABLE_WABI): ... here.  Control it with newly added
> --disable-compat-libstdcxx-abi.
> * configure: Rebuilt.
> * doc/html/manual/configure.html: Document it.
> ---
>  libstdc++-v3/acinclude.m4   |   26 ++
>  libstdc++-v3/configure  |   49 
> ++-
>  libstdc++-v3/doc/html/manual/configure.html |2 +
>  3 files changed, 67 insertions(+), 10 deletions(-)
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 51a08bcc8b1d0..4ef5d5e98c2be 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -707,10 +707,34 @@ AC_DEFUN([GLIBCXX_EXPORT_FLAGS], [
># OPTIMIZE_CXXFLAGS = -O3 -fstrict-aliasing -fvtable-gc
>AC_SUBST(OPTIMIZE_CXXFLAGS)
>
> -  WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2"
> +  WARN_FLAGS="-Wall -Wextra -Wwrite-strings -Wcast-qual"
>AC_SUBST(WARN_FLAGS)
> +
> +  GLIBCXX_ENABLE_WABI
>  ])
>
> +dnl
> +dnl Enable -Wabi=2 if not overridden by --disable-compat-libstdcxx-abi.
> +dnl
> +AC_DEFUN([GLIBCXX_ENABLE_WABI], [
> +  # Default.
> +  WARN_FLAGS_WABI=\ -Wabi=2
> +  AC_MSG_CHECKING([for --disable-compat-libstdcxx-abi])
> +  AC_ARG_ENABLE([compat-libstdcxx-abi],

We have the GLIBCXX_ENABLE macro to simplify creating new --enable options.

> +AC_HELP_STRING([--disable-compat-libstdcxx-abi],
> +  [Disable backward-compatibility ABI symbols)]),

There's a stray ')' here.

> +[case "$enableval" in
> +  yes) AC_MSG_RESULT(enabled$WARN_FLAGS_WABI) ;;
> +  no)  WARN_FLAGS_WABI=
> +  AC_MSG_RESULT(disabled) ;;
> +  *)   AC_MSG_RESULT(unsupported)
> +  AC_MSG_ERROR([Unsupported argument to enable/disable compat 
> libstdc++ abi]);;
> + esac], [
> +  AC_MSG_RESULT(defaulting to enabled$WARN_FLAGS_WABI)
> + ])
> +
> +  WARN_FLAGS="$WARN_FLAGS$WARN_FLAGS_WABI"
> +])
>
>  dnl
>  dnl All installation directory information is determined here.

[...]

> diff --git a/libstdc++-v3/doc/html/manual/configure.html 
> b/libstdc++-v3/doc/html/manual/configure.html
> index 346b5d345cd1b..8636b2360d9f0 100644
> --- a/libstdc++-v3/doc/html/manual/configure.html
> +++ b/libstdc++-v3/doc/html/manual/configure.html
> @@ -108,6 +108,8 @@
> then the [time.clock] implementation will use a system call to access
> the realtime and monotonic clocks, which is significantly slower than
> the C library's clock_gettime function.
> + class="code">--disable-compat-libstdcxx-abiDisables
> +backward-compatibility ABI symbols.
>   class="code">--enable-libstdcxx-debugBuild separate 
> debug libraries in addition to what is normally built.
> By default, the debug libraries are compiled with
>  CXXFLAGS='-g3 -O0 -fno-inline'

This should be in doc/xml/manual/configure.xml too, which is used to
generate the HTML using docbook. Otherwise this change will be lost
next time the docs are regenerated.

The description here in the docs (and the name of the configure
option) seem much too vague. Libstdc++ has dozens, probably hundreds,
of "backward-compatibility ABI symbols", and this only affects touches
a tiny handful of them. Just the aliases created automatically by the
compiler for mangling changes, right? From the name of the configure
option and the doc entry, I'd expect it to also affect e.g.
src/c++11/compatibility-*.cc and maybe to have some interaction with
--disable-libstdcxx-dual-abi.

The change seems fine in principle, but needs a better name and doc

Re: docs: document early break support and pragma novector

[Richard Biener]

On Tue, 16 Apr 2024, Tamar Christina wrote:

> docs: document early break support and pragma novector

OK.

> ---
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 
> b4c602a523717c1d64333e44aefb60ba0ed02e7a..aceecb86f17443cfae637e90987427b98c42f6eb
>  100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -200,6 +200,34 @@ a work-in-progress.
>  for indicating parameters that are expected to be null-terminated
>  strings.
>
> +  
> +The vectorizer now supports vectorizing loops which contain any number 
> of early breaks.
> +This means loops such as:
> +
> + int z[100], y[100], x[100];
> + int foo (int n)
> + {
> +   int res = 0;
> +   for (int i = 0; i < n; i++)
> + {
> +y[i] = x[i] * 2;
> +res += x[i] + y[i];
> +
> +if (x[i] > 5)
> +  break;
> +
> +if (z[i] > 5)
> +  break;
> +
> + }
> +   return res;
> + }
> +
> +can now be vectorized on a number of targets.  In this first version any
> +input data sources must either have a statically known size at compile 
> time
> +or the vectorizer must be able to determine based on auxillary 
> information
> +that the accesses are aligned.
> +  
>  
>  
>  New Languages and Language specific improvements
> @@ -231,6 +259,9 @@ a work-in-progress.
>previous options -std=c2x, -std=gnu2x
>and -Wc11-c2x-compat, which are deprecated but remain
>supported.
> +  GCC supports a new pragma #pragma GCC novector to
> +  indicate to the vectorizer not to vectorize the loop annotated with the
> +  pragma.
>  
>  
>  C++
> @@ -400,6 +431,9 @@ a work-in-progress.
>warnings are enabled for C++ as well
>The DR 2237 code no longer gives an error, it emits
>a -Wtemplate-id-cdtor warning instead
> +  GCC supports a new pragma #pragma GCC novector to
> +  indicate to the vectorizer not to vectorize the loop annotated with the
> +  pragma.
>  
>  
>  Runtime Library (libstdc++)
> 
> 
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)