Re: [PATCH v4] Introduce attribute sym

[Alexandre Oliva via Gcc-patches]

On Jul 22, 2023, Fangrui Song  wrote:

> I wonder whether this attribute can be named "alias" without arguments.

Erhm...  Maybe I'm missing something about your suggestion, but without
arguments, how would we tell the compiler the symbol name of the
additional alias we want for the definition?

Maybe, instead of no arguments, we could use something like:

  attribute (alias (..., "alt_sym_name"))

but I don't find that clearer, and I have a hunch that the
implementation would be significantly more convoluted.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

Introduce -msmp to select /lib_smp/ on ppc-vx6

[Alexandre Oliva via Gcc-patches]

The .spec files used for linking on ppc-vx6, when the rtp-smp runtime
is selected, add -L flags for /lib_smp/ and /lib/.

There was a problem, though: although /lib_smp/ and /lib/ were to be
searched in this order, and the specs files do that correctly, the
compiler would search /lib/ first regardless, because
STARTFILE_PREFIX_SPEC said so, and specs files cannot override that.

With this patch, we arrange for the presence of -msmp to affect
STARTFILE_PREFIX_SPEC, so that the compiler searches /lib_smp/ rather
than /lib/ for crt files.  A separate patch for GNAT ensures that when
the rtp-smp runtime is selected, -msmp is passed to the compiler
driver for linking, along with the --specs flags.

Preapproved by Olivier Hainque.  I'm checking this in.


for  gcc/ChangeLog

* config/vxworks-smp.opt: New.  Introduce -msmp.
* config.gcc: Enable it on powerpc* vxworks prior to 7r*.
* config/rs6000/vxworks.h (STARTFILE_PREFIX_SPEC): Choose
lib_smp when -msmp is present in the command line.
* doc/invoke.texi: Document it.
---
 gcc/config.gcc  |2 +-
 gcc/config/rs6000/vxworks.h |2 +-
 gcc/config/vxworks-smp.opt  |   25 +
 gcc/doc/invoke.texi |9 -
 4 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/vxworks-smp.opt

diff --git a/gcc/config.gcc b/gcc/config.gcc
index eba69a463be0d..7438e0be4a2c0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3046,7 +3046,7 @@ powerpc*-wrs-vxworks7r*)
 powerpc-wrs-vxworks*)
tm_file="${tm_file} elfos.h gnu-user.h freebsd-spec.h rs6000/sysv4.h"
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-ppccomm 
rs6000/t-vxworks"
-   extra_options="${extra_options} rs6000/sysv4.opt"
+   extra_options="${extra_options} rs6000/sysv4.opt vxworks-smp.opt"
extra_headers="${extra_headers} ppc-asm.h"
case ${target} in
   *-vxworksmils*)
diff --git a/gcc/config/rs6000/vxworks.h b/gcc/config/rs6000/vxworks.h
index 690e92439b94f..f38b4bd1dff2f 100644
--- a/gcc/config/rs6000/vxworks.h
+++ b/gcc/config/rs6000/vxworks.h
@@ -206,7 +206,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #undef  STARTFILE_PREFIX_SPEC
 #define STARTFILE_PREFIX_SPEC  \
- "%{mrtp:%{!shared:/lib/usr/lib/ppc/PPC32/common}}"
+ "%{mrtp:%{!shared:/lib%{msmp:_smp}/usr/lib/ppc/PPC32/common}}"
 
 /* For aggregates passing, use the same, consistent ABI as Linux.  */
 #define AGGREGATE_PADDING_FIXED 0
diff --git a/gcc/config/vxworks-smp.opt b/gcc/config/vxworks-smp.opt
new file mode 100644
index 0..5ef1521634ab5
--- /dev/null
+++ b/gcc/config/vxworks-smp.opt
@@ -0,0 +1,25 @@
+; Options for VxWorks configurations where smp/!smp variants of the
+; system libraries are installed in separate locations.
+;
+; Copyright (C) 2023 Free Software Foundation, Inc.
+; Contributed by AdaCore.
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; .
+
+msmp
+Driver Target RejectNegative
+Select VxWorks SMP C runtimes for linking.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 104766f446d11..adb10a3528dae 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1403,7 +1403,7 @@ See RS/6000 and PowerPC Options.
 -mpointer-size=@var{size}}
 
 @emph{VxWorks Options}
-@gccoptlist{-mrtp  -non-static  -Bstatic  -Bdynamic
+@gccoptlist{-mrtp  -msmp  -non-static  -Bstatic  -Bdynamic
 -Xbind-lazy  -Xbind-now}
 
 @emph{x86 Options}
@@ -32442,6 +32442,13 @@ GCC can generate code for both VxWorks kernels and 
real time processes
 (RTPs).  This option switches from the former to the latter.  It also
 defines the preprocessor macro @code{__RTP__}.
 
+@opindex msmp
+@item -msmp
+Select SMP runtimes for linking.  Not available on architectures other
+than PowerPC, nor on VxWorks version 7 or later, in which the selection
+is part of the VxWorks build configuration and the library paths are the
+same for either choice.
+
 @opindex non-static
 @item -non-static
 Link an RTP executable against shared libraries rather than static


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH v4] Introduce attribute sym

[Alexandre Oliva via Gcc-patches]

On Jul 20, 2023, Richard Biener  wrote:

> I wonder if we could have shared some of the cgraph/varasm bits
> with the symver attribute handling?  It's just a new 'sym' but
> without the version part?

Possibly.  process_common_attributes could be a good place to create the
alias decl, like symver does.  But that wouldn't cover clones of C++
ctors and dtors, that get variants of the named sym, nor sym attributes
attached to C++ classes.  Aside from these special cases, it is an alias
declaration, without much else to do, which is not very much unlike
symver, but the named sym alias needs to be introduced in the symtab
early enough that other (non-sym) alias declarations can refer to it,
which symver doesn't need to worry about.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH v4] Introduce attribute sym

[Alexandre Oliva via Gcc-patches]

On Jul 18, 2023, Richard Biener  wrote:

> I think the __symver__ attribute does something similar already so
> maybe use __attribute__((__sym__("foo")))?

Cool, thanks, that will do.  Regstrapped on x86_64-linux-gnu.  Ok to
install?


This patch introduces an attribute to add extra asm names (aliases)
for a decl when its definition is output.  The main goal is to ease
interfacing C++ with Ada, as C++ mangled names have to be named, and
in some cases (e.g. when using stdint.h typedefs in function
arguments) the symbol names may vary across platforms.

The attribute is usable in C and C++, presumably in all C-family
languages.  It can be attached to global variables and functions.  In
C++, it can also be attached to class types, namespace-scoped
variables and functions, static data members, member functions,
explicit instantiations and specializations of template functions,
members and classes.

When applied to constructors or destructor, additional sym aliases
with _Base and _Del suffixes are defined for variants other than
complete-object ones.  This changes the assumption that clones always
carry the same attributes as their abstract declarations, so there is
now a function to adjust them.

C++ also had a bug in which attributes from local extern declarations
failed to be propagated to a preexisting corresponding
namespace-scoped decl.  I've fixed that, and adjusted acc tests that
distinguished between C and C++ in this regard.

Applying the attribute to class types is only valid in C++, and the
effect is to attach the alias to the RTTI object associated with the
class type.

for  gcc/ChangeLog

* attribs.cc: Include cgraph.h.
(decl_attributes): Allow late introduction of sym alias in
types.
(create_sym_alias_decl, create_sym_alias_decls): New.
* attribs.h: Declare them.
(FOR_EACH_SYM_ALIAS): New macro.
* cgraph.cc (cgraph_node::create): Create sym alias decls.
* varpool.cc (varpool_node::get_create): Create sym alias
decls.
* cgraph.h (symtab_node::remap_sym_alias_target): New.
* symtab.cc (symtab_node::remap_sym_alias_target): Define.
* cgraphunit.cc (cgraph_node::analyze): Create alias_target
node if needed.
(analyze_functions): Fixup visibility of implicit alias only
after its node is analyzed.
* doc/extend.texi (sym): Document for variables, functions and
types.

for  gcc/ada/ChangeLog

* doc/gnat_rm/interfacing_to_other_languages.rst: Mention
attribute sym to give RTTI symbols mnemonic names.
* doc/gnat_ugn/the_gnat_compilation_model.rst: Mention
aliases.  Fix incorrect ref to C1 ctor variant.

for  gcc/c-family/ChangeLog

* c-ada-spec.cc (pp_asm_name): Use first sym alias if
available.
* c-attribs.cc (handle_sym_attribute): New.
(c_common_attribute_table): Add sym.
(handle_copy_attribute): Do not copy sym attribute.

for  gcc/c/ChangeLog

* c-decl.cc (duplicate_decls): Remap sym alias target.

for  gcc/cp/ChangeLog

* class.cc (adjust_clone_attributes): New.
(copy_fndecl_with_name, build_clone): Call it.
* cp-tree.h (adjust_clone_attributes): Declare.
(update_sym_alias_interface): Declare.
(update_tinfo_sym_alias): Declare.
* decl.cc (duplicate_decls): Remap sym_alias target.
Adjust clone attributes.
(grokfndecl): Tentatively create sym alias decls after
adding attributes in e.g. a template member function explicit
instantiation.
* decl2.cc (cplus_decl_attributes): Update tinfo sym alias.
(copy_interface, update_sym_alias_interface): New.
(determine_visibility): Update sym alias interface.
(tentative_decl_linkage, import_export_decl): Likewise.
* name-lookup.cc: Include target.h and cgraph.h.
(push_local_extern_decl_alias): Merge attributes with
namespace-scoped decl, and drop duplicate sym alias.
* optimize.cc (maybe_clone_body): Re-adjust attributes after
cloning them.  Update sym alias interface.
* rtti.cc: Include attribs.h and cgraph.h.
(get_tinfo_decl): Copy sym attributes from type to tinfo decl.
Create sym alias decls.
(update_tinfo_sym_alias): New.

for  gcc/testsuite/ChangeLog

* c-c++-common/goacc/declare-1.c: Adjust.
* c-c++-common/goacc/declare-2.c: Adjust.
* c-c++-common/torture/attr-sym-1.c: New.
* c-c++-common/torture/attr-sym-2.c: New.
* c-c++-common/torture/attr-sym-3.c: New.
* c-c++-common/torture/attr-sym-4.c: New.
* g++.dg/torture/attr-sym-1.C: New.
* g++.dg/torture/attr-sym-2.C: New.
* g++.dg/torture/attr-sym-3.C: New.
* g++.dg/torture/attr-sym-4.C: New.
* g++.dg/torture/attr-sym-5.C: New.
---
 .../doc/gnat_rm/interfacing_to_other_languages.rst |6 +
 

Re: [PATCH v3] Introduce attribute reverse_alias

[Alexandre Oliva via Gcc-patches]

Hello, Nathan,

On Jul 15, 2023, Nathan Sidwell  wrote:

> Not commenting on the semantics, but the name seems unfortunate (hello
> bikeshed).

Yeah, it's a bit challenging to express the concept, when the notion of
"alias" is kind of symmetric between decl and target, but the
previously-implemented extension attaches it to decl rather than to
target.  I tried "extra alias" before, but that didn't fly either.

Maybe I should give up and just recommend the use of asm ("name")
instead of allowing alternative names (AKA aliases, in the dictionary
sense; oh, the irony) to be introduced for a decl?  Maybe that would be
simpler and enough to sidestep the problem of varying mangled names when
trying to import into Ada (or defining C++ aliases for) C++ symbols that
use standard types in signatures that are not fundamental types, such as
size_t.  That they mangle differently depending on what size_t is
typedef'ed to makes for some undesirable inconvenience, which this
attribute attempts to alleviate.

> The documentation starts with 'attribute causes @var{name}
> to be emitted as an alias to the definition'.  So not emitting a
> 'reverse alias', whatever that might be.

It's reverse in that it doesn't alias another declaration, as in the
preexisting meaning of the alias attribute, it adds an alias for the
present declaration.

> It doesn;t seem to mention how reverse alias differs from 'alias'.
> Why would 'alias' not DTRT?

contrast:

int foo();
int __attribute__ ((alias ("foo"))) bar();

static_assert ( == ); // ok

with:

int __attribute__ ((reverse_alias ("bar"))) foo();

static_assert ( == ); // error, bar is not a C++ symbol

int __attribute__ ((alias ("bar"))) baz(); // ok

static_assert ( == ); // ok

asm (".quad bar"); // ok, even in other TUs
asm (".quad foo"); // not necessarily ok, foo's symbol may be mangled
asm (".quad baz"); // not necessarily ok, baz's symbol may be mangled

> Is is emitting a an additiona symbol -- ie, something like 'altname'.

Yup.  Is there precedent for this attribute name elsewhere?  I think it
could work.

> Is that symbol known in the current TU, or other TUs?

Only in the assembly/linker name space, not in any C++ namespace.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH v3] Introduce attribute reverse_alias

[Alexandre Oliva via Gcc-patches]

This patch introduces an attribute to add extra aliases to a symbol
when its definition is output.  The main goal is to ease interfacing
C++ with Ada, as C++ mangled names have to be named, and in some cases
(e.g. when using stdint.h typedefs in function arguments) the symbol
names may vary across platforms.

The attribute is usable in C and C++, presumably in all C-family
languages.  It can be attached to global variables and functions.  In
C++, it can also be attached to namespace-scoped variables and
functions, static data members, member functions, explicit
instantiations and specializations of template functions, members and
classes.

When applied to constructors or destructor, additional reverse_aliases
with _Base and _Del suffixes are defined for variants other than
complete-object ones.  This changes the assumption that clones always
carry the same attributes as their abstract declarations, so there is
now a function to adjust them.

C++ also had a bug in which attributes from local extern declarations
failed to be propagated to a preexisting corresponding
namespace-scoped decl.  I've fixed that, and adjusted acc tests that
distinguished between C and C++ in this regard.

Applying the attribute to class types is only valid in C++, and the
effect is to attach the alias to the RTTI object associated with the
class type.

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

This is refreshed and renamed from earlier versions that named the
attribute 'exalias', and that AFAICT got stuck in name bikeshedding.
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551614.html


for  gcc/ChangeLog

* attribs.cc: Include cgraph.h.
(decl_attributes): Allow late introduction of reverse_alias in
types.
(create_reverse_alias_decl, create_reverse_alias_decls): New.
* attribs.h: Declare them.
(FOR_EACH_REVERSE_ALIAS): New macro.
* cgraph.cc (cgraph_node::create): Create reverse_alias decls.
* varpool.cc (varpool_node::get_create): Create reverse_alias
decls.
* cgraph.h (symtab_node::remap_reverse_alias_target): New.
* symtab.cc (symtab_node::remap_reverse_alias_target):
Define.
* cgraphunit.cc (cgraph_node::analyze): Create alias_target
node if needed.
(analyze_functions): Fixup visibility of implicit alias only
after its node is analyzed.
* doc/extend.texi (reverse_alias): Document for variables,
functions and types.

for  gcc/ada/ChangeLog

* doc/gnat_rm/interfacing_to_other_languages.rst: Mention
attribute reverse_alias to give RTTI symbols mnemonic names.
* doc/gnat_ugn/the_gnat_compilation_model.rst: Mention
attribute reverse_alias.  Fix incorrect ref to C1 ctor variant.

for  gcc/c-family/ChangeLog

* c-ada-spec.cc (pp_asm_name): Use first reverse_alias if
available.
* c-attribs.cc (handle_reverse_alias_attribute): New.
(c_common_attribute_table): Add reverse_alias.
(handle_copy_attribute): Do not copy reverse_alias.

for  gcc/c/ChangeLog

* c-decl.cc (duplicate_decls): Remap reverse_alias target.

for  gcc/cp/ChangeLog

* class.cc (adjust_clone_attributes): New.
(copy_fndecl_with_name, build_clone): Call it.
* cp-tree.h (adjust_clone_attributes): Declare.
(update_reverse_alias_interface): Declare.
(update_tinfo_reverse_alias): Declare.
* decl.cc (duplicate_decls): Remap reverse_alias target.
Adjust clone attributes.
(grokfndecl): Tentatively create reverse_alias decls after
adding attributes in e.g. a template member function explicit
instantiation.
* decl2.cc (cplus_decl_attributes): Update tinfo
reverse_alias.
(copy_interface, update_reverse_alias_interface): New.
(determine_visibility): Update reverse_alias interface.
(tentative_decl_linkage, import_export_decl): Likewise.
* name-lookup.cc: Include target.h and cgraph.h.
(push_local_extern_decl_alias): Merge attributes with
namespace-scoped decl, and drop duplicate reverse_alias.
* optimize.cc (maybe_clone_body): Re-adjust attributes after
cloning them.  Update reverse_alias interface.
* rtti.cc: Include attribs.h and cgraph.h.
(get_tinfo_decl): Copy reverse_alias attributes from type to
tinfo decl.  Create reverse_alias decls.
(update_tinfo_reverse_alias): New.

for  gcc/testsuite/ChangeLog

* c-c++-common/goacc/declare-1.c: Adjust.
* c-c++-common/goacc/declare-2.c: Adjust.
* c-c++-common/torture/attr-revalias-1.c: New.
* c-c++-common/torture/attr-revalias-2.c: New.
* c-c++-common/torture/attr-revalias-3.c: New.
* c-c++-common/torture/attr-revalias-4.c: New.
* g++.dg/torture/attr-revalias-1.C: New.
* g++.dg/torture/attr-revalias-2.C: New.
* g++.dg/torture/attr-revalias-3.C: 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 28, 2023, Qing Zhao  wrote:

> In summary, Ada’s Boolean variables (whether it’s hardened or not) are
> represented as
> enumeration types in GNU IR.

Not quite.  Only boolean types with representation clauses are.  Those
without (such as Standard.Boolean) are BOOLEAN_TYPEs.  But those without
a representation clause are not so relevant and could be disregarded,
for purposes of this conversation.

> FE takes care of the converting between non-boolean_type_node
> enumeration types and boolean_type_node as needed, no special handling
> in Middle end.

> So, is this exactly the same situation as the new hardbool attribute
> for C being implemented in this patch?

That's correct.

> (Another question, for Ada’s Boolean variables, does the ada FE also
> insert BUILT_IN_TRAP when
>   The value is neither true_value nor false_value?)

Ada raises exceptions when validity checking fails; such as upon using a
boolean variable with a representation clause holds a value that is
neither true nor false.

>> The middle-end doesn't know (and ATM cannot know) that those represented
>> as enumeration types are conceptually booleans, so they are treated as
>> enumeration types, not as booleans.

> They should know it’s a boolean if using the lookup_attribute to get
> the attribute info -:)

I meant boolean types that have a representation clause but are not
hardbools.  Those don't have any attribute whatsoever.

>> You mean more than what's in the patch posted last week?
> No, the updated doc is good I think.

Great, thanks

> So, from my current understanding, a summary on my major concern and
> the possible solution to this concern:

That was a good summary.

> Is it necessary to fix such inconsistency?

I don't think it is even desirable.

Initialization of static variables is well-defined, one is allowed to
count on a specific value after initialization, and we have that
covered.

Automatic variables, OTOH, when not explicitly initialized, may hold
undefined, random, even malformed values.  Picking an initializer to
make them predictable needs not follow the semantics of zero
initialization for static variables.  =pattern makes it clear that using
something other than zero initialization is useful to catch errors.  The
Ada language standard even suggests that compilers may set uninitialized
variables to out-of-range values so as to catch this sort of error.  So,
though it might seem desirable, for symmetry, to have automatic
variables implicitly initialized similarly to static variables, it's not
clear that doing so serves a useful purpose, at least for such types as
hardened booleans, that are *intended* to catch malformed values.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[testsuite] tolerate enabled but missing language frontends

[Alexandre Oliva via Gcc-patches]

When a language is enabled but we run the testsuite against a tree in
which the frontend compiler is not present, help.exp fails.  It
recognizes the output pattern for a disabled language, but not a
missing frontend.  Extend the pattern so that it covers both cases.

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


for  gcc/testsuite/ChangeLog

* lib/options.exp (check_for_options_with_filter): Handle
missing frontend compiler like disabled language.
---
 gcc/testsuite/lib/options.exp |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/options.exp b/gcc/testsuite/lib/options.exp
index 30e6e50d703dc..a4b15c14f9c6c 100644
--- a/gcc/testsuite/lib/options.exp
+++ b/gcc/testsuite/lib/options.exp
@@ -59,7 +59,7 @@ proc check_for_options_with_filter { language gcc_options 
exclude \
 set gcc_output [gcc_target_compile $srcfname $filebase.x executable 
$gcc_options]
 remote_file build delete $srcfname $filebase.x $filebase.gcno
 
-if {[regexp -- "compiler not installed on this system" $gcc_output]} {
+if {[regexp -- "compiler not installed on this system|cannot execute" 
$gcc_output]} {
unsupported "$test: $language compiler not available"
return
 }

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH v3] Introduce strub: machine-independent stack scrubbing

[Alexandre Oliva via Gcc-patches]

Hello, Qing,

On Jun 27, 2023, Qing Zhao  wrote:

> I am wondering why stack scrubbing, proposed in this patch series, cannot do 
> the stack scrubbing in the routine’s epilogue similar as
> register scrubbing?

There were multiple considerations that led to this design decision:

- Stack scrubbing in epilogues would be highly target-dependent

An epilogue expected to scrub the stack of its containing function would
not usually be able to call memset; there might not even be registers
available to do the cleaning, let alone to do it efficiently.  Since
epilogues are output after register allocation, the epilogue code
generator would have to allocate registers itself to do the job,
avoiding call-saved registers (that would have to be restored before
scrubbing the stack holding them), those holding return values, and
taking care of any machine- or ABI-specific conventions that apply to
epilogues.

- Exception Handling

Raising or propagating an exception requires a function's stack frame to
be active.  It wouldn't be possible for e.g. a cleanup handler to clean
up the stack frame holding it and then propagating the exception: either
the scrubbing would have to leave much of the stack frame alone for
propagation to work, or it would scrub too much and propagation would
fail.

So we had to devise a way for stack frames to be scrubbed and protect
the sensitive data in them even if an exception is raised or propagated
out of the sensitive frame.

- Variable frame size

Though many functions have static frame sizes, there are cases in which
a function dynamically allocates and releases stack space, and that
extra space should be scrubbed as well.  So the improvements out of a
known frame size are not a given, and we may need a watermark to handle
the general case.

Now consider that this watermark needs to survive past the point in
which the epilogue restores call-saved registers, so that the save area
can be scrubbed.  Call-clobbered registers might not be available, or
need scrubbing themselves.

A caller-owned watermark relieves the callee from these contradictory
requirements, enables the register pointing to the watermark to be
reused by the callee as soon as it's no longer needed; aggregation of
scrubbing, passing on the watermark when tail-calling another scrubbed
subprogram; caller and callee to be compiled separately, circumstances
in which the caller (in the strub("at-calls") mode) wouldn't know how
much stack space used by the callee is to be scrubbed.

- Watermark as in/out argument

Thus, watermarks, and caller-based scrubbing were required, so we might
as well use the same strategy for non-exceptional exit paths to make it
portable.

We've explored various possibilities of watermark passing to reduce the
impact on the ABI:

-- a single global variable wouldn't do in multi-threaded programs;
we need per-thread stack information.  TLS is not available on every
target, it's emulated with high overhead on some, and even when it
doesn't use part of the thread's stack for static thread-local
storage, each caller of a scrubbing function would have to preserve
that variable somehow (presumably in its own stack frame) before
reusing it to communicate with its callee.

-- a thread-local pointer to a heap-allocated parallel stack of
stack-scrubbing ranges might avoid holding the watermarks in the
stack, or passing pointers to them as arguments, leaving the entire
scrub range management in the library.  that would make the __strub_*
library components heavy enough that inlining them would not be
viable.  Furthermore, making such low-level APIs heap allocators
normally makes for problems of async-signal safety, and prevents heap
implementations from relying on such low-level APIs.

-- using the static chain machinery to convey to scrubbed callees
access to the callee's watermark seems viable, if onerous, but the
chained records live in the stack anyway, and there are targets that
do not support static chains.

-- an out parameter might do for "amount of stack used", but
making it an in/out watermark enabled aggregation and tail-calling;
early set-and-forget on fixed-size stack frames; and assured
initialization, even in case of an early asynchronous exception.

- Internal scrubbing

Though we have implemented strub("internal") through wrappers that call
the actual function and then scrub its stack space, we have envisioned
an alternate implementation that, through machine-specific support,
performs actual internal scrubbing, arranging the stack frame in such a
way that epilogues and EH cleanups can scrub most, if not all of the
stack frame (analogous to how the wrapper only scrubs the wrapped frame,
not its own), and taking advantage of constant frame sizes where
possible.  At least with variable frame sizes, the amount of stack space
to be scrubbed in the epilogue (or in an EH cleanup) will have to be
held in a local variable or somesuch, and at least for nonleaf
functions, that surely will end up in the stack 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 26, 2023, Qing Zhao  wrote:

>>> For hardbool variables, what 0x00 represents if it’s not false or true
>>> value?
>> 
>> It depends on how hardbool is parameterized.  One may pick 0x00 or 0xFE
>> as the representations for true or false, or neither, in which case the
>> trivial initializer will end up as a trapping value.

> Okay, then, this looks like a good behavior (trapping with
> -ftrival-auto-var-init most of the time,
>  i.e, when neither 0x00 or 0xFE was chosen as the representations for true or 
> false), 
> it will urge the user to fix the uninitialized hardbool variables.

Agreed

 I'd probably have arranged for the front-end to create the initializer
 value, because expansion time is too late to figure it out: we may not
 even have the front-end at hand any more, in case of lto compilation.
>> 
>>> Is the hardbool attribute information available during the rtl expansion 
>>> phase?
>> 
>> It is in the sense that the attribute lives on, but c_hardbool_type_attr
>> is a frontend function, it cannot be called from e.g. lto1.
> does lookup_attribute work for this attribute during rtl expansion?
> (Still a little confusing here)

Yes, the hardbool attribute would be there in C.
But not in Ada.

And that should be fine, because Ada hardbool is handled entirely in the
frontend, as are non-hardened booleans with representation clauses, that
become enumeration types without any distinguishing feature.

>> The hardbool attribute is also implemented in Ada, but there it only
>> affects validity checking in the front end: Boolean types in Ada are
>> Enumeration types, and there is standard syntax to specify the
>> representations for true and false.  AFAICT, once we translate GNAT IR
>> to GNU IR, hardened booleans would not be recognizable as boolean types.
>> Even non-hardened booleans with representation clauses would.

> So, right now, the GNU IR represents Ada’s boolean type as enumeration type? 

All Ada boolean types are defined by the language as enumeration types:

  There is a predefined enumeration type named Boolean, [declared in the
  visible part of package Standard].  It has the two enumeration
  literals False and True ordered with the relation False < True.  Any
  descendant of the predefined type Boolean is called a boolean type.

However, boolean types without representation clauses are mapped to the
language-independent boolean_type_node.  Those that do are mapped to
enumeration types.

>> So
>> handling these differently from other enumeration types, to make them
>> closer to booleans, would be a bit of a challenge,

> is there any special handling in GNU IR when representing Ada’s
> boolean type as enumeration type?
> Any issue right now?

Not that I'm aware of.  The front end takes care of converting between
non-boolean_type_node enumeration types and boolean_type_node as needed,
so that the GNU IR needs no extra information.

>> and a
>> backwards-compatibility issue (because such booleans have already been
>> handled in the present way since the introduction of -ftrivial-* back in
>> GCC12)

> With the new hardbool attribute added for C, an original bool type
> becomes an enumeration type logically,

There's no change to the original bool type.

Only hardbool types are represented as enumeration types in C.

In Ada, boolean types with representation clauses are still represented
as enumeration types, whether or not they're hardbool.

> But such information is not passed to middle end through GNU IR, So,
> in GCC middle-end, We still treat such type as boolean, not an
> enumeration type.

The middle-end doesn't know (and ATM cannot know) that those represented
as enumeration types are conceptually booleans, so they are treated as
enumeration types, not as booleans.

>> static hbool zeroinit; /* False, stored as (char)0x5a.  */
>> auto hbool uninit; /* Undefined, may trap.  */

> For the hardbool variable "uninit", -ftrivial-auto-var-init=zero will
> initialize it to zero, and it will trap during runtime.
> And at the same time, -ftrivial-auto-var-init=pattern will initialize
> it to 0xfe, and it will trap during runtime, too.

> I think these are good behaviors, just need to be documented. 

You mean more than what's in the patch posted last week?

>> 
>>> And this is a very reasonable initial value for Boolean variables,
>> 
>> Agreed.  The all-zeros bit pattern is not so great for booleans that use
>> alternate representations, though, such as the following standard Ada:
>> 
>> type MyBool is new Boolean;
>> for MyBool use (16#5a#, 16#a5#);
>> for MyBool'Size use 8;
>> 
>> or for biased variables such as:
>> 
>> X : Integer range 254 .. 507;
>> for X'Size use 8; -- bits, so a biased representation is required.
>> 
>> Just to make things more interesting, I chose a range for X that causes
>> the compiler to represent 0xfe as 0x00 in in the byte that holds X, but
>> that places the 0xfe pattern just out of the range :-) So with
>> 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 16, 2023, Alexandre Oliva  wrote:

> On Aug  9, 2022, Alexandre Oliva  wrote:
>> Ping?

> Ping?  Refreshed, added setting of ENUM_UNDERLYING_TYPE, retested on
> x86_64-linux-gnu (also on gcc-13).

Here's a consolidated patch incorporating the doc and test patchlets
sent out in response to Qing's and Berhard's suggestions.

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


Introduce hardbool attribute for C

This patch introduces hardened booleans in C.  The hardbool attribute,
when attached to an integral type, turns it into an enumerate type
with boolean semantics, using the named or implied constants as
representations for false and true.

Expressions of such types decay to _Bool, trapping if the value is
neither true nor false, and _Bool can convert implicitly back to them.
Other conversions go through _Bool first.


for  gcc/c-family/ChangeLog

* c-attribs.cc (c_common_attribute_table): Add hardbool.
(handle_hardbool_attribute): New.
(type_valid_for_vector_size): Reject hardbool.
* c-common.cc (convert_and_check): Skip warnings for convert
and check for hardbool.
(c_hardbool_type_attr_1): New.
* c-common.h (c_hardbool_type_attr): New.

for  gcc/c/ChangeLog

* c-typeck.cc (convert_lvalue_to_rvalue): Decay hardbools.
* c-convert.cc (convert): Convert to hardbool through
truthvalue.
* c-decl.cc (check_bitfield_type_and_width): Skip enumeral
truncation warnings for hardbool.
(finish_struct): Propagate hardbool attribute to bitfield
types.
(digest_init): Convert to hardbool.

for  gcc/ChangeLog

* doc/extend.texi (hardbool): New type attribute.
* doc/invoke.texi (-ftrivial-auto-var-init): Document
representation vs values.

for  gcc/testsuite/ChangeLog

* gcc.dg/hardbool-err.c: New.
* gcc.dg/hardbool-trap.c: New.
* gcc.dg/hardbool.c: New.
* gcc.dg/hardbool-s.c: New.
* gcc.dg/hardbool-us.c: New.
* gcc.dg/hardbool-i.c: New.
* gcc.dg/hardbool-ul.c: New.
* gcc.dg/hardbool-ll.c: New.
* gcc.dg/hardbool-5a.c: New.
* gcc.dg/hardbool-s-5a.c: New.
* gcc.dg/hardbool-us-5a.c: New.
* gcc.dg/hardbool-i-5a.c: New.
* gcc.dg/hardbool-ul-5a.c: New.
* gcc.dg/hardbool-ll-5a.c: New.
---
 gcc/c-family/c-attribs.cc |   98 -
 gcc/c-family/c-common.cc  |   21 
 gcc/c-family/c-common.h   |   18 
 gcc/c/c-convert.cc|   14 +++
 gcc/c/c-decl.cc   |   10 ++
 gcc/c/c-typeck.cc |   31 ++-
 gcc/doc/extend.texi   |   64 ++
 gcc/doc/invoke.texi   |   21 
 gcc/testsuite/gcc.dg/hardbool-err.c   |   31 +++
 gcc/testsuite/gcc.dg/hardbool-trap.c  |   13 +++
 gcc/testsuite/gcc.dg/torture/hardbool-5a.c|6 +
 gcc/testsuite/gcc.dg/torture/hardbool-i-5a.c  |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-i.c |5 +
 gcc/testsuite/gcc.dg/torture/hardbool-ll-5a.c |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-ll.c|5 +
 gcc/testsuite/gcc.dg/torture/hardbool-s-5a.c  |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-s.c |5 +
 gcc/testsuite/gcc.dg/torture/hardbool-ul-5a.c |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-ul.c|5 +
 gcc/testsuite/gcc.dg/torture/hardbool-us-5a.c |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-us.c|5 +
 gcc/testsuite/gcc.dg/torture/hardbool.c   |  118 +
 22 files changed, 496 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/hardbool-err.c
 create mode 100644 gcc/testsuite/gcc.dg/hardbool-trap.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-i-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-i.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ll-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ll.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-s-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-s.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ul-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ul.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-us-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-us.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool.c

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index c12211cb4d499..365319e642b1a 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -176,6 +176,7 @@ static tree handle_objc_root_class_attribute (tree *, tree, 
tree, int, bool *);
 static tree handle_objc_nullability_attribute (tree *, tree, tree, int, bool 
*);
 static tree 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 22, 2023, Bernhard Reutner-Fischer  wrote:

> On Wed, 21 Jun 2023 22:08:55 -0300
> Alexandre Oliva  wrote:

>> Thanks for the test.
>> 
>> Did you mean for me to incorporate it into the patch, or do you mean to
>> contribute it separately, if the feature happens to be accepted?

> These were your tests that i quoted

Aaah.  I didn't look too closely, I just assumed you'd tweaked something
in there.

>> > I don't see explicit tests with _Complex nor __complex__. Would we
>> > want to check these here, or are they handled thought the "underlying"
>> > tests above?  
>> 
>> Good question.  The notion of using complex types to hold booleans
>> hadn't even crossed my mind.

> Maybe it is not real, it just sparkled through somehow.

Is it imaginary, then? :-D

>> On the other, there doesn't seem to be any useful case for them.  Can
>> anyone think of one?

> We could either not reject other such uses and wait or we could reject
> them and equally wait for complaints. I would not dare to bet who pops
> up first, fuzzers or users

I bet on fuzzers :-)

> it was just a thought (i mentioned tinfoil hat, did i ;).

indeed ;-)

Having verified that it gets rejected (phew :-) I'm inclined to add it
to the test you quoted and be done with it.  If a reason ever comes up
to support it, the test can be adjusted accordingly.

>> 
>> > I'd welcome a fortran interop note in the docs  
>> 
>> Is there any good place for such interop notes?  I'm not sure I'm
>> best-suited to write them up, since Fortran is not a language I'm
>> very familiar with, but I suppose I could give it a try.

> I'd append to your extend.texi hunk below the para about uninitialized a
> note to the effect of:
> Note: Types annotated with this attribute may not be Fortran
> interoperable.

I'm not comfortable single-casing Fortran like that.  I expect other
languages could face similar interop issues when relying on
single-language extensions.  How about:

  Since this is a language extension only available in C, interoperation
  with other languages may pose difficulties.  It should interoperate
  with Ada Booleans defined with the same size and equivalent
  representation clauses, and with enumerations or other languages'
  integral types that correspond to C's chosen integral type.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2023, Qing Zhao via Gcc-patches  wrote:

> -ftrivial-auto-var-init has been in GCC since GCC12.  

*nod*.  IIRC I started designing hardbool in GCC10, but the first
complete implementation was for GCC11.

> The decision to use 0x00 for zero-initiation, 0xfe for pattern-initiation
> has been discussed thoroughly during the design phase. -:)

*nod*, and it's a good one

> Since this hardbool attribute will also  be a security feature, users that 
> seek
> security features of GCC will likely ask the same question for these two
> features.

> So, their interaction is better to be at least documented. That’s my main 
> point.

*nod*.  At first, I thought the ideal place to clarify the issue was in
the documentation for the option, because there's nothing exceptional
about the option's behavior when it comes to hardbool specifically.  But
it doesn't hurt to mention it in both places, so I did.  How about the
incremental patchlet below (at the end)?

> For normal Boolean variables, 0x00 is false, this is a reasonable init
> value with zero-initialization.

*nod*.  I was surprised by zero initialization of (non-hardened)
booleans even when pattern is requested, but not consistently
(e.g. boolean fields of a larger struct would still get
pattern-initialized IIUC).  I'd have expected pattern would translate to
nonzero and thus to true, rather than false.

> For hardbool variables, what 0x00 represents if it’s not false or true
> value?

It depends on how hardbool is parameterized.  One may pick 0x00 or 0xFE
as the representations for true or false, or neither, in which case the
trivial initializer will end up as a trapping value.

>> I'd probably have arranged for the front-end to create the initializer
>> value, because expansion time is too late to figure it out: we may not
>> even have the front-end at hand any more, in case of lto compilation.

> Is the hardbool attribute information available during the rtl expansion 
> phase?

It is in the sense that the attribute lives on, but c_hardbool_type_attr
is a frontend function, it cannot be called from e.g. lto1.

The hardbool attribute is also implemented in Ada, but there it only
affects validity checking in the front end: Boolean types in Ada are
Enumeration types, and there is standard syntax to specify the
representations for true and false.  AFAICT, once we translate GNAT IR
to GNU IR, hardened booleans would not be recognizable as boolean types.
Even non-hardened booleans with representation clauses would.  So
handling these differently from other enumeration types, to make them
closer to booleans, would be a bit of a challenge, and a
backwards-compatibility issue (because such booleans have already been
handled in the present way since the introduction of -ftrivial-* back in
GCC12)

>> Now, I acknowledge that the decision to make implicit
>> zero-initialization of boolean types set them to the value for false,
>> rather than to all-bits-zero representation, is a departure from common
>> practice of zero-initialization yielding logical zero.

> Dont’s quite understand the above, for normal boolean variables,

Sorry, I meant hardened boolean types.  This was WRT to the design
decision that led to this bit in the documentation:

typedef char __attribute__ ((__hardbool__ (0x5a))) hbool;
[...]
static hbool zeroinit; /* False, stored as (char)0x5a.  */
auto hbool uninit; /* Undefined, may trap.  */
  
> And this is a very reasonable initial value for Boolean variables,

Agreed.  The all-zeros bit pattern is not so great for booleans that use
alternate representations, though, such as the following standard Ada:

   type MyBool is new Boolean;
   for MyBool use (16#5a#, 16#a5#);
   for MyBool'Size use 8;

or for biased variables such as:

  X : Integer range 254 .. 507;
  for X'Size use 8; -- bits, so a biased representation is required.

Just to make things more interesting, I chose a range for X that causes
the compiler to represent 0xfe as 0x00 in in the byte that holds X, but
that places the 0xfe pattern just out of the range :-) So with
-ftrivial-auto-var-init=zero, X = 254, whereas with
-ftrivial-auto-var-init=pattern, it fails validity checking, and might
come out as 508 if that's disabled.

> From my understanding, only with the introduction of “hardbool”
> attribute, all-bits-zero will not be equal to the
> logical false anymore. 

Ada booleans have long allowed nonzero representations for false.


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 772209c1793e8..ae7867bb35696 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8774,6 +8774,12 @@ on the bits held in the storage (re)used for the 
variable, if any, and
 on optimizations the compiler may perform on the grounds that using
 uninitialized values invokes undefined behavior.
 
+Users of @option{-ftrivial-auto-var-init} should be aware that the bit
+patterns used as its trivial initializers are @emph{not} converted to
+@code{hardbool} types, so using variables 

[PATCH v3] Add leafy mode for zero-call-used-regs

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2023, Qing Zhao via Gcc-patches  wrote:

> It’s better to add this definition earlier in the list of the “three
> basic values”, to make it “four basic values”, like the following:

Oh, my, sorry for being so dense, I had managed to miss that bit all
this time somehow :-(

> The sentence "This value is mainly to provide users a more efficient mode to 
> zero 
> call-used registers in leaf functions.” just for your reference,
> the wording can certainly be improved.  -:)

:-)  got it, thanks.  How about this?


Add leafy mode for zero-call-used-regs

Introduce 'leafy' to auto-select between 'used' and 'all' for leaf and
nonleaf functions, respectively.

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


for  gcc/ChangeLog

* doc/extend.texi (zero-call-used-regs): Document leafy and
variants thereof.
* flag-types.h (zero_regs_flags): Add LEAFY_MODE, as well as
LEAFY and variants.
* function.cc (gen_call_ued_regs_seq): Set only_used for leaf
functions in leafy mode.
* opts.cc (zero_call_used_regs_opts): Add leafy and variants.

for  gcc/testsuite/ChangeLog

* c-c++-common/zero-scratch-regs-leafy-1.c: New.
* c-c++-common/zero-scratch-regs-leafy-2.c: New.
* gcc.target/i386/zero-scratch-regs-leafy-1.c: New.
* gcc.target/i386/zero-scratch-regs-leafy-2.c: New.
---
 gcc/doc/extend.texi|   30 ++--
 gcc/flag-types.h   |5 +++
 gcc/function.cc|3 ++
 gcc/opts.cc|4 +++
 .../c-c++-common/zero-scratch-regs-leafy-1.c   |   15 ++
 .../c-c++-common/zero-scratch-regs-leafy-2.c   |   21 ++
 .../gcc.target/i386/zero-scratch-regs-leafy-1.c|   12 
 .../gcc.target/i386/zero-scratch-regs-leafy-2.c|   16 +++
 8 files changed, 103 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/zero-scratch-regs-leafy-1.c
 create mode 100644 gcc/testsuite/c-c++-common/zero-scratch-regs-leafy-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/zero-scratch-regs-leafy-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/zero-scratch-regs-leafy-2.c

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 852f6b629bea8..739c40368f556 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -4349,7 +4349,7 @@ through registers.
 In order to satisfy users with different security needs and control the
 run-time overhead at the same time, the @var{choice} parameter provides a
 flexible way to choose the subset of the call-used registers to be zeroed.
-The three basic values of @var{choice} are:
+The four basic values of @var{choice} are:
 
 @itemize @bullet
 @item
@@ -4362,10 +4362,16 @@ the function.
 
 @item
 @samp{all} zeros all call-used registers.
+
+@item
+@samp{leafy} behaves like @samp{used} in a leaf function, and like
+@samp{all} in a nonleaf function.  This makes for leaner zeroing in leaf
+functions, where the set of used registers is known, and that may be
+enough for some purposes of register zeroing.
 @end itemize
 
 In addition to these three basic choices, it is possible to modify
-@samp{used} or @samp{all} as follows:
+@samp{used}, @samp{all}, and @samp{leafy} as follows:
 
 @itemize @bullet
 @item
@@ -4412,10 +4418,28 @@ zeros all call-used registers that pass arguments.
 @item all-gpr-arg
 zeros all call-used general purpose registers that pass
 arguments.
+
+@item leafy
+Same as @samp{used} in a leaf function, and same as @samp{all} in a
+nonleaf function.
+
+@item leafy-gpr
+Same as @samp{used-gpr} in a leaf function, and same as @samp{all-gpr}
+in a nonleaf function.
+
+@item leafy-arg
+Same as @samp{used-arg} in a leaf function, and same as @samp{all-arg}
+in a nonleaf function.
+
+@item leafy-gpr-arg
+Same as @samp{used-gpr-arg} in a leaf function, and same as
+@samp{all-gpr-arg} in a nonleaf function.
+
 @end table
 
 Of this list, @samp{used-arg}, @samp{used-gpr-arg}, @samp{all-arg},
-and @samp{all-gpr-arg} are mainly used for ROP mitigation.
+@samp{all-gpr-arg}, @samp{leafy-arg}, and @samp{leafy-gpr-arg} are
+mainly used for ROP mitigation.
 
 The default for the attribute is controlled by @option{-fzero-call-used-regs}.
 @end table
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 2e650bf1c487c..0d2dab1b99dd4 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -348,6 +348,7 @@ namespace zero_regs_flags {
   const unsigned int ONLY_GPR = 1UL << 2;
   const unsigned int ONLY_ARG = 1UL << 3;
   const unsigned int ENABLED = 1UL << 4;
+  const unsigned int LEAFY_MODE = 1UL << 5;
   const unsigned int USED_GPR_ARG = ENABLED | ONLY_USED | ONLY_GPR | ONLY_ARG;
   const unsigned int USED_GPR = ENABLED | ONLY_USED | ONLY_GPR;
   const unsigned int USED_ARG = ENABLED | ONLY_USED | ONLY_ARG;
@@ -356,6 +357,10 @@ namespace zero_regs_flags {
   const unsigned int ALL_GPR = 

[testsuite] note pitfall in how outputs.exp sets gld

[Alexandre Oliva via Gcc-patches]

This patch documents a glitch in gcc.misc-tests/outputs.exp: it checks
whether the linker is GNU ld, and uses that to decide whether to
expect collect2 to create .ld1_args files under -save-temps, but
collect2 bases that decision on whether HAVE_GNU_LD is set, which may
be false zero if the linker in use is GNU ld.  Configuring
--with-gnu-ld fixes this misalignment.  Without that, atsave tests are
likely to fail, because without HAVE_GNU_LD, collect2 won't use @file
syntax to run the linker (so it won't create .ld1_args files).

Long version: HAVE_GNU_LD is set when (i) DEFAULT_LINKER is set during
configure, pointing at GNU ld; (ii) --with-gnu-ld is passed to
configure; or (iii) config.gcc sets gnu_ld=yes.  If a port doesn't set
gnu_ld, and the toolchain isn't configured so as to assume GNU ld,
configure and thus collect2 conservatively assume the linker doesn't
support @file arguments.

But outputs.exp can't see how configure set HAVE_GNU_LD (it may be
used to test an installed compiler), and upon finding that the linker
used by the compiler is GNU ld, it will expect collect2 to use @file
arguments when running the linker.  If that assumption doesn't hold,
atsave tests will fail.

Does it make sense to put this in?  I'd like to preserve this knowledge
somehow, and I suppose this would be most useful for someone observing
these failures and trying to figure out why they come about, so this
seems the best place for them.  Ok to install?


for  gcc/testsuite/ChangeLog

* outputs.exp (gld): Note a known mismatch and record a
workaround.
---
 gcc/testsuite/gcc.misc-tests/outputs.exp |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 7ee355034ccaf..9f44cbdb0b5d5 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -50,7 +50,15 @@ if !$skip_lto {
 set ltop [check_linker_plugin_available]
 }
 
-# Check for GNU LD.  Some files like .ld1_args depend on this.
+# Check for GNU LD.  Some files like .ld1_args depend on this.  This
+# should really be testing whether HAVE_GNU_LD was set by configure.
+# If we find GNU ld here, but the compiler wasn't configured
+# --with-gnu-ld or with DEFAULT_LINKER pointing at GNU ld, on a target
+# that doesn't set gnu_ld=yes unconditionally, configure and thus
+# collect2 will conservatively assume there's no support for @file in
+# the linker, but our atfile tests will expect ld1_args files to be
+# created, and thus fail.  Configuring the compiler --with-gnu-ld
+# fixes this.
 set gld [check_effective_target_gld]
 
 # Prepare additional options to be used for linking.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Introduce -finline-stringops (was: Re: [RFC] Introduce -finline-memset-loops)

[Alexandre Oliva via Gcc-patches]

On Jun  2, 2023, Alexandre Oliva  wrote:

> Introduce -finline-stringops

Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620472.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 21, 2023, Qing Zhao  wrote:

> I see that you have testing case to check the above built_in_trap call
> is generated by FE.
> Do you have a testing case to check the trap is happening at runtime? 

I have written such tests, using type-punning, but I don't think our
testing infrastructure could take trapping as success and other results
as failure.

> So, when -ftrivial-auto-var-init presents, what’s the behavior for the
> hardened Boolean auto variables?

Good question.  This option was not even available when hardbool was
designed and implemented.  (tests) The deferred_init internal function
initializes with bit-patterns 0x00 or 0xfe, regardless of type, when the
data lives in memory, and otherwise forces the 0x00 bit pattern for
booleans, variable-sized types, types that cannot be accessed with a
single mode or for modes that don't have a set pattern.

It's hard for me to tell what "correct" or "expected" would be here.
Enumerators don't seem to be given special treatment.  Checked
enumerators, constrained integral subtypes, none of these would get
well-formed values or even checking at the assignments.

If I were to design this option myself, I'd probably arrange for it to
handle booleans (including hardened booleans) by zero-initializing as
false and pattern-initializing as true, though I realize that this could
be very confusing if one chose to use 0xfe as the value for false and/or
0x00 as the value for true.

I'd probably have arranged for the front-end to create the initializer
value, because expansion time is too late to figure it out: we may not
even have the front-end at hand any more, in case of lto compilation.


But with the current description and implementation, I guess the
behavior is correct, if not ideal: the bit patterns refer to the
representation, rather than to the language interpretation of the value.
When it comes ot integral types, they may match, but floating-point,
fixed fractional types, offsets and multipliers, even boolean member of
larger structs...  not so much: the effect is that of a memset, rather
than that of an assignment of zero or of the pattern to a variable.

Now, I acknowledge that the decision to make implicit
zero-initialization of boolean types set them to the value for false,
rather than to all-bits-zero representation, is a departure from common
practice of zero-initialization yielding logical zero.  That was unusual
enough that I thought it worth mentioning in the docs.


> This might need to be documented and also handled correctly. 

I suppose the place to document this distinction between logical values
and representation would be under -ftrivial-auto-var-init.  That's
likely where someone using that option would look for guidance on how it
interacts with unusual types, and where exceptions to general
expectations WRT initialization would go.  Do you concur?

That said, it probalby makes sense to refer to / mention that
-ftrivial-auto-var-init does not special-case hardened booleans in the
hardened booleans documentation.  I wonder if there are other
conflicting options I'm not even aware of.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs

[Alexandre Oliva via Gcc-patches]

Hello, Qing,

On Jun 16, 2023, Qing Zhao  wrote:

> As I mentioned in the previous round of review, I think that the documentation
>  might need to add more details on what’s the LEAFY mode,
> The purpose of it, and how to use it, provide more details to the end-users.

I'm afraid I'm having difficulty picturing what it is that you're
looking for.  The proposal incorporates, by reference, all the
documentation for 'used' and for 'all', and the way to use it is no
different.

>> +Same as @samp{used} in a leaf function, and same as @samp{all} in a
>> +nonleaf function.

If there was documentation on how to choose between e.g. all and used, I
suppose I could build on that to add this intermediate choice, but...  I
can't find any such docs, and I'm uncertain on whether adding that would
be useful to begin with.

Did you have something else in mind?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

Thanks for the test.

Did you mean for me to incorporate it into the patch, or do you mean to
contribute it separately, if the feature happens to be accepted?

On Jun 19, 2023, Bernhard Reutner-Fischer  wrote:

> I don't see explicit tests with _Complex nor __complex__. Would we
> want to check these here, or are they handled thought the "underlying"
> tests above?

Good question.  The notion of using complex types to hold booleans
hadn't even crossed my mind.

On the one hand, there doesn't seem to be reason to rule them out, and
that could go for literally any other type.

On the other, there doesn't seem to be any useful case for them.  Can
anyone think of one?

> I'd welcome a fortran interop note in the docs

Is there any good place for such interop notes?  I'm not sure I'm
best-suited to write them up, since Fortran is not a language I'm
very familiar with, but I suppose I could give it a try.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Jun 16, 2023, Thomas Koenig  wrote:

> So, such a type would be incompatible with vanilla LOGICAL variables
> and with C interop logical variables.

Yeah, it would.  It's something else, and if you choose to use such a
type in an interface, it would need to be handled as such.  Presumably,
absent direct support in the desired language, using the underlying type
and the explicitly chosen constants would work.

This is nothing to call home about.  It's not unusual for languages to
support features that are not directly representable in other languages.
And this is one that isn't even hard to work around.

But I'd first doubt the wisdom of whoever adds such a type to a
cross-language interface.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs

[Alexandre Oliva via Gcc-patches]

Hello, Qing,

On Oct 27, 2022, Qing Zhao  wrote:


> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva  wrote:
>> I'm sure there are other scenarios in which keeping at least the
>> possibility of 'all' is useful.
> Okay.


> i.e, instead introducing a new MODE “LEAFY_MODE” and a new user
> sub-option, for LEAF functions, only
> Clear its’ used registers even for “ALL”.

> However, since there is need to clear the un-used registers for leaf
> functions. It looks like it is needed to provide
> This new sub-option to users.

> Is this clear this time?

Yeah, I guess I understand what you mean.  But since there are cases in
which clearing all (call-clobbered) registers in a leaf function is
useful, I suppose it makes sense to offer both possibilities.

If there was a default operation mode for -fzero-call-used-regs, I guess
it would make sense to consider leafy the default, rather than all, but
since there isn't, and it always has to be specified explicitly, that's
not something to be considered.

So the available choices are:

1. introduce 'leafy' as a separate mode, leaving 'all' alone

2. change the behavior of 'all' to that of the proposed 'leafy', and either

2.a) add another mode that retains the currently-useful behavior of 'all',
   or

2.b) make the current behavior of 'all' no longer available

Personally, I find 1. the least disruptive to existing users of
-fzero-call-used-regs.  If we were introducing the option now, maybe 2.a
would be more sensible, but at this point, changing the meaning of 'all'
seems to be a disservice to security-sensitive users.

Those who would prefer the leaner operation on leaf functions can then
switch to 'leafy' mode, but that's better than finding carefully-crafted
code relying on the current behavior of 'all' for security suddenly
changes from under them, isn't it?


That said, I'm willing to implement the alternate change, if changing
the expected behavior is preferred over offering a different choice, if
needed to get closure on this feature.

For now, I'm just pinging the refreshed and retested patch.
Ok to install?


Add leafy mode for zero-call-used-regs

Introduce 'leafy' to auto-select between 'used' and 'all' for leaf and
nonleaf functions, respectively.


for  gcc/ChangeLog

* doc/extend.texi (zero-call-used-regs): Document leafy and
variants thereof.
* flag-types.h (zero_regs_flags): Add LEAFY_MODE, as well as
LEAFY and variants.
* function.cc (gen_call_ued_regs_seq): Set only_used for leaf
functions in leafy mode.
* opts.cc (zero_call_used_regs_opts): Add leafy and variants.

for  gcc/testsuite/ChangeLog

* c-c++-common/zero-scratch-regs-leafy-1.c: New.
* c-c++-common/zero-scratch-regs-leafy-2.c: New.
* gcc.target/i386/zero-scratch-regs-leafy-1.c: New.
* gcc.target/i386/zero-scratch-regs-leafy-2.c: New.
---
 gcc/doc/extend.texi|   22 ++--
 gcc/flag-types.h   |5 +
 gcc/function.cc|3 +++
 gcc/opts.cc|4 
 .../c-c++-common/zero-scratch-regs-leafy-1.c   |   15 ++
 .../c-c++-common/zero-scratch-regs-leafy-2.c   |   21 +++
 .../gcc.target/i386/zero-scratch-regs-leafy-1.c|   12 +++
 .../gcc.target/i386/zero-scratch-regs-leafy-2.c|   16 +++
 8 files changed, 96 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/zero-scratch-regs-leafy-1.c
 create mode 100644 gcc/testsuite/c-c++-common/zero-scratch-regs-leafy-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/zero-scratch-regs-leafy-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/zero-scratch-regs-leafy-2.c

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b5592502734e..f8b0bb53ef5d4 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -4412,10 +4412,28 @@ zeros all call-used registers that pass arguments.
 @item all-gpr-arg
 zeros all call-used general purpose registers that pass
 arguments.
+
+@item leafy
+Same as @samp{used} in a leaf function, and same as @samp{all} in a
+nonleaf function.
+
+@item leafy-gpr
+Same as @samp{used-gpr} in a leaf function, and same as @samp{all-gpr}
+in a nonleaf function.
+
+@item leafy-arg
+Same as @samp{used-arg} in a leaf function, and same as @samp{all-arg}
+in a nonleaf function.
+
+@item leafy-gpr-arg
+Same as @samp{used-gpr-arg} in a leaf function, and same as
+@samp{all-gpr-arg} in a nonleaf function.
+
 @end table
 
-Of this list, @samp{used-arg}, @samp{used-gpr-arg}, @samp{all-arg},
-and @samp{all-gpr-arg} are mainly used for ROP mitigation.
+Of this list, @samp{used-arg}, @samp{used-gpr-arg}, @samp{leafy-arg},
+@samp{leafy-gpr-arg}, @samp{all-arg}, and @samp{all-gpr-arg} are mainly
+used for ROP mitigation.
 
 The default for the 

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva via Gcc-patches]

On Aug  9, 2022, Alexandre Oliva  wrote:

> Ping?

Ping?  Refreshed, added setting of ENUM_UNDERLYING_TYPE, retested on
x86_64-linux-gnu (also on gcc-13).


Introduce hardbool attribute for C

This patch introduces hardened booleans in C.  The hardbool attribute,
when attached to an integral type, turns it into an enumerate type
with boolean semantics, using the named or implied constants as
representations for false and true.

Expressions of such types decay to _Bool, trapping if the value is
neither true nor false, and _Bool can convert implicitly back to them.
Other conversions go through _Bool first.


for  gcc/c-family/ChangeLog

* c-attribs.cc (c_common_attribute_table): Add hardbool.
(handle_hardbool_attribute): New.
(type_valid_for_vector_size): Reject hardbool.
* c-common.cc (convert_and_check): Skip warnings for convert
and check for hardbool.
(c_hardbool_type_attr_1): New.
* c-common.h (c_hardbool_type_attr): New.

for  gcc/c/ChangeLog

* c-typeck.cc (convert_lvalue_to_rvalue): Decay hardbools.
* c-convert.cc (convert): Convert to hardbool through
truthvalue.
* c-decl.cc (check_bitfield_type_and_width): Skip enumeral
truncation warnings for hardbool.
(finish_struct): Propagate hardbool attribute to bitfield
types.
(digest_init): Convert to hardbool.

for  gcc/ChangeLog

* doc/extend.texi (hardbool): New type attribute.

for  gcc/testsuite/ChangeLog

* gcc.dg/hardbool-err.c: New.
* gcc.dg/hardbool-trap.c: New.
* gcc.dg/hardbool.c: New.
* gcc.dg/hardbool-s.c: New.
* gcc.dg/hardbool-us.c: New.
* gcc.dg/hardbool-i.c: New.
* gcc.dg/hardbool-ul.c: New.
* gcc.dg/hardbool-ll.c: New.
* gcc.dg/hardbool-5a.c: New.
* gcc.dg/hardbool-s-5a.c: New.
* gcc.dg/hardbool-us-5a.c: New.
* gcc.dg/hardbool-i-5a.c: New.
* gcc.dg/hardbool-ul-5a.c: New.
* gcc.dg/hardbool-ll-5a.c: New.
---
 gcc/c-family/c-attribs.cc |   98 -
 gcc/c-family/c-common.cc  |   21 
 gcc/c-family/c-common.h   |   18 
 gcc/c/c-convert.cc|   14 +++
 gcc/c/c-decl.cc   |   10 ++
 gcc/c/c-typeck.cc |   31 ++-
 gcc/doc/extend.texi   |   52 +++
 gcc/testsuite/gcc.dg/hardbool-err.c   |   28 ++
 gcc/testsuite/gcc.dg/hardbool-trap.c  |   13 +++
 gcc/testsuite/gcc.dg/torture/hardbool-5a.c|6 +
 gcc/testsuite/gcc.dg/torture/hardbool-i-5a.c  |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-i.c |5 +
 gcc/testsuite/gcc.dg/torture/hardbool-ll-5a.c |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-ll.c|5 +
 gcc/testsuite/gcc.dg/torture/hardbool-s-5a.c  |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-s.c |5 +
 gcc/testsuite/gcc.dg/torture/hardbool-ul-5a.c |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-ul.c|5 +
 gcc/testsuite/gcc.dg/torture/hardbool-us-5a.c |6 +
 gcc/testsuite/gcc.dg/torture/hardbool-us.c|5 +
 gcc/testsuite/gcc.dg/torture/hardbool.c   |  118 +
 21 files changed, 460 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/hardbool-err.c
 create mode 100644 gcc/testsuite/gcc.dg/hardbool-trap.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-i-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-i.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ll-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ll.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-s-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-s.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ul-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-ul.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-us-5a.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool-us.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/hardbool.c

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index c12211cb4d499..365319e642b1a 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -176,6 +176,7 @@ static tree handle_objc_root_class_attribute (tree *, tree, 
tree, int, bool *);
 static tree handle_objc_nullability_attribute (tree *, tree, tree, int, bool 
*);
 static tree handle_signed_bool_precision_attribute (tree *, tree, tree, int,
bool *);
+static tree handle_hardbool_attribute (tree *, tree, tree, int, bool *);
 static tree handle_retain_attribute (tree *, tree, tree, int, bool *);
 static tree handle_fd_arg_attribute (tree *, tree, tree, int, bool *);
 
@@ -293,6 +294,8 @@ const struct attribute_spec 

[libstdc++] [testsuite] expect zero entropy matching implementation

[Alexandre Oliva via Gcc-patches]

random_device::get_entropy() returns 0.0 when _GLIBCXX_USE_DEV_RANDOM
is not defined, but the test expects otherwise.  Adjust.

Regstrapped on x86_64-linux-gnu, also tested on aarch64-rtems6.  Ok to
install?


for  libstdc++-v3/ChangeLog

* testsuite/26_numerics/random/random_device/entropy.cc:
Expect get_entropy to return zero when _GLIBCXX_USE_DEV_RANDOM
is not defined.
---
 .../26_numerics/random/random_device/entropy.cc|8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc 
b/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc
index 9f529f5d81410..3e6872c8a613f 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc
@@ -13,7 +13,13 @@ test01()
   VERIFY( std::random_device(token).entropy() == 0.0 );
 
   using result_type = std::random_device::result_type;
+#ifdef _GLIBCXX_USE_DEV_RANDOM
   const double max = std::numeric_limits::digits;
+#else
+  // random_device::entropy() always returns 0.0 when
+  // _GLIBCXX_USE_DEV_RANDOM is not defined.
+  const double max = 0.0;
+#endif
 
   for (auto token : { "/dev/random", "/dev/urandom" })
 if (__gnu_test::random_device_available(token))
@@ -30,7 +36,7 @@ test01()
   VERIFY( entropy == max );
 }
 
-for (auto token : { "getentropy", "arc4random" })
+  for (auto token : { "getentropy", "arc4random" })
 if (__gnu_test::random_device_available(token))
 {
   const double entropy = std::random_device(token).entropy();

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[libstdc++] [testsuite] xfail dbl from_chars for aarch64 rtems ldbl

[Alexandre Oliva via Gcc-patches]

rtems, like vxworks, uses fast-float doubles for from_chars even for
long double, so it loses precision, so expect the long double bits to
fail on aarch64.

Regstrapped on x86_64-linux-gnu, also tested on aarch64-rtems6.  Ok to
install?


for  libstdc++-v3/ChangeLog

* testsuite/20_util/from_chars/4.cc: Skip long double on
aarch64-rtems.
---
 libstdc++-v3/testsuite/20_util/from_chars/4.cc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/4.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
index 206e18daeb229..76e07df9d2bf3 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/4.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
@@ -18,7 +18,7 @@
 //  is supported in C++14 as a GNU extension
 // { dg-do run { target c++14 } }
 // { dg-add-options ieee }
-// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* 
x86_64-*-vxworks* } }
+// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-rtems* 
aarch64-*-vxworks* x86_64-*-vxworks* } }
 
 #include 
 #include 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

libstdc++-v3: do not duplicate some math functions when using newlib

[Alexandre Oliva via Gcc-patches]

Contributing a patch by Joel Brobecker .
Regstrapped on x86_64-linux-gnu just to be sure, also tested with
aarch64-rtems6.  I'm going to put this in later this week if there
aren't any objections.


When running the libstdc++ testsuite on AArch64 RTEMS, we noticed
that about 25 tests are failing during the link, due to the "sqrtl"
function being defined twice:
  - once inside RTEMS' libm;
  - once inside our libstdc++.

One test that fails, for instance, would be 26_numerics/complex/13450.cc.

In comparing libm and libstdc++, we found that libstc++ also
duplicates "hypotf", and "hypotl".

For "sqrtl" and "hypotl", the symbosl come a unit called
from math_stubs_long_double.cc, while "hypotf" comes from
the equivalent unit for the float version, called math_stubs_float.cc.
Those units are always compiled in libstdc++ and provide our own
version of various math routines when those are missing from
the target system. The definition of those symbols is predicated
on the existance of various macros provided by c++config.h, which
themselves are predicated by the corresponding HAVE_xxx macros
in config.h.

One key element behind what's happening, here, is that the target
uses newlib, and therefore GCC was configured --with-newlib.
The section of libstdc++v3's configure script that handles which math
functions are available has a newlib-specific section, and that
section provides a hardcoded list of symbols.

For "hypotf", this commit fixes the issue by doing the same
as for the other routines already declared in that section.
I verified by inspection in the newlib code that this function
should always be present, so hardcoding it in our configure
script should not be an issue.

For the math routines handling doubles ("sqrtl" and "hypotl"),
however, I do not believe we can assume that newlib's libm
will always provide them. Therefore, this commit fixes that
part of the issue by ading a compile-check for "sqrtl" and "hypotl".
And while at it, we also include checks for all the other math
functions that math_stubs_long_double.cc re-implements, allowing
us to be resilient to future newlib enhancements adding support
for more functions.

libstdc++-v3/ChangeLog:

* configure.ac ["x${with_newlib}" = "xyes"]: Define
HAVE_HYPOTF.  Add compile-checks for various long double
math functions as well.
* configure: Regenerate.
---
 libstdc++-v3/configure| 1179 +
 libstdc++-v3/configure.ac |9 
 2 files changed, 1188 insertions(+)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 354c566b0055c..bda8053ecc279 100755
[omitted]
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 0abe54e7b9a21..9770c1787679f 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -349,6 +349,7 @@ else
 AC_DEFINE(HAVE_FLOORF)
 AC_DEFINE(HAVE_FMODF)
 AC_DEFINE(HAVE_FREXPF)
+AC_DEFINE(HAVE_HYPOTF)
 AC_DEFINE(HAVE_LDEXPF)
 AC_DEFINE(HAVE_LOG10F)
 AC_DEFINE(HAVE_LOGF)
@@ -360,6 +361,14 @@ else
 AC_DEFINE(HAVE_TANF)
 AC_DEFINE(HAVE_TANHF)
 
+dnl # Support for the long version of some math libraries depends on
+dnl # architecture and newlib version.  So test for their availability
+dnl # rather than hardcoding that information.
+GLIBCXX_CHECK_MATH_DECLS([
+  acosl asinl atan2l atanl ceill coshl cosl expl fabsl floorl fmodl
+  frexpl hypotl ldexpl log10l logl modfl powl sinhl sinl sqrtl
+  tanhl tanl])
+
 AC_DEFINE(HAVE_ICONV)
 AC_DEFINE(HAVE_MEMALIGN)
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] fix frange_nextafter odr violation

[Alexandre Oliva via Gcc-patches]

On Jun  9, 2023, Richard Biener  wrote:

> On Thu, Jun 8, 2023 at 4:38 PM Alexandre Oliva via Gcc-patches
>  wrote:

>> C++ requires inline functions to be declared inline and defined in
>> every translation unit that uses them.  frange_nextafter is used in
>> gimple-range-op.cc but it's only defined as inline in
>> range-op-float.cc.  Drop the extraneous inline specifier.

> OK

>> for  gcc/ChangeLog
>> 
>> * range-op-float.cc (frange_nextafter): Drop inline.
>> (frelop_early_resolve): Add static.
>> (frange_float): Likewise.

The problem is also present in gcc-13.  Ok there as well?  Regstrapped
on x86_64-linux-gnu.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

[PATCH] fix frange_nextafter odr violation

[Alexandre Oliva via Gcc-patches]

C++ requires inline functions to be declared inline and defined in
every translation unit that uses them.  frange_nextafter is used in
gimple-range-op.cc but it's only defined as inline in
range-op-float.cc.  Drop the extraneous inline specifier.

Other non-static inline functions in range-op-float.cc are not
referenced elsewhere, so I'm making them static.

Bootstrapping on x86_64-linux-gnu, along with other changes that exposed
the problem; it's already into stage3, and it wouldn't get past stage2
before.  Ok to install?


for  gcc/ChangeLog

* range-op-float.cc (frange_nextafter): Drop inline.
(frelop_early_resolve): Add static.
(frange_float): Likewise.
---
 gcc/range-op-float.cc |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index a99a6b01ed835..d6da2aa701ee3 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -255,7 +255,7 @@ maybe_isnan (const frange , const frange )
 // Floating version of relop_early_resolve that takes into account NAN
 // and -ffinite-math-only.
 
-inline bool
+static inline bool
 frelop_early_resolve (irange , tree type,
  const frange , const frange ,
  relation_trio rel, relation_kind my_rel)
@@ -272,7 +272,7 @@ frelop_early_resolve (irange , tree type,
 
 // Set VALUE to its next real value, or INF if the operation overflows.
 
-inline void
+void
 frange_nextafter (enum machine_mode mode,
  REAL_VALUE_TYPE ,
  const REAL_VALUE_TYPE )
@@ -2878,7 +2878,7 @@ namespace selftest
 
 // Build an frange from string endpoints.
 
-inline frange
+static inline frange
 frange_float (const char *lb, const char *ub, tree type = float_type_node)
 {
   REAL_VALUE_TYPE min, max;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[testsuite] bump some tsvc timeouts

[Alexandre Oliva via Gcc-patches]

Several tests are timing out when targeting x86-*-vxworks with qemu.

Bump their timeout factor.


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/tsvc/vect-tsvc-s116.c: Bump timeout factor.
* gcc.dg/vect/tsvc/vect-tsvc-s241.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s254.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s271.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s2711.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s2712.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s276.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-vdotr.c: Likewise.
---
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s116.c  |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s241.c  |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s254.c  |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s271.c  |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2711.c |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2712.c |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s276.c  |1 +
 gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vdotr.c |3 ++-
 8 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s116.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s116.c
index 93d16b3f50d16..9702ec8f52302 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s116.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s116.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s241.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s241.c
index 14b4188e57b0e..95652d1415307 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s241.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s241.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 1.5 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s254.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s254.c
index 06e9b0a849dc4..92f00d8af6416 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s254.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s254.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s271.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s271.c
index 0c9b67d2fd707..03f806e74d6e6 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s271.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s271.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2711.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2711.c
index c1a5f35473874..4510fae890042 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2711.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2711.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2712.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2712.c
index 765d230b54c1d..92e9742874a50 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2712.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s2712.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s276.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s276.c
index 7389c61e127a2..7ca7166a46d1e 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s276.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s276.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vdotr.c 
b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vdotr.c
index 80ed9f81e506f..013d3f4473c5b 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vdotr.c
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-vdotr.c
@@ -3,6 +3,7 @@
 
 /* { dg-additional-options "--param vect-epilogues-nomask=0" } */
 /* { dg-require-effective-target vect_float } */
+/* { dg-timeout-factor 2 } */
 
 #include "tsvc.h"
 
@@ -38,4 +39,4 @@ int main (int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
\ No newline at end of file
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */


-- 
Alexandre 

Re: [RFC] Introduce -finline-memset-loops

[Alexandre Oliva via Gcc-patches]

On Jan 19, 2023, Alexandre Oliva  wrote:

> Would it make more sense to extend it, even constrained by the
> limitations mentioned above, or handle memset only?  In the latter case,
> would it still make sense to adopt a command-line option that suggests a
> broader effect than it already has, even if it's only a hopeful future
> extension?  -finline-all-stringops[={memset,memcpy,...}], that you
> suggested, seems to be a reasonable and extensible one to adopt.

I ended up implementing all of memset, memcpy, memmove, and memcmp:

Introduce -finline-stringops

try_store_by_multiple_pieces was added not long ago, enabling
variable-sized memset to be expanded inline when the worst-case
in-range constant length would, using conditional blocks with powers
of two to cover all possibilities of length and alignment.

This patch introduces -finline-stringops[=fn] to request expansions to
start with a loop, so as to still take advantage of known alignment
even with long lengths, but without necessarily adding store blocks
for every power of two.

This makes it possible for the supported stringops (memset, memcpy,
memmove, memset) to be expanded, even if storing a single byte per
iteration.  Surely efficient implementations can run faster, with a
pre-loop to increase alignment, but that would likely be excessive for
inline expansions.

Still, in some cases, such as in freestanding environments, users
prefer to inline such stringops, especially those that the compiler
may introduce itself, even if the expansion is not as performant as a
highly optimized C library implementation could be, to avoid
depending on a C runtime library.

Regstrapped on x86_64-linux-gnu, also bootstrapped with
-finline-stringops enabled by default, and tested with arm, aarch, 32-
and 64-bit riscv with gcc-12.  Ok to install?


for  gcc/ChangeLog

* expr.cc (emit_block_move_hints): Take ctz of len.  Obey
-finline-stringops.  Use oriented or sized loop.
(emit_block_move): Take ctz of len, and pass it on.
(emit_block_move_via_sized_loop): New.
(emit_block_move_via_oriented_loop): New.
(emit_block_move_via_loop): Take incr.  Move an incr-sized
block per iteration.
(emit_block_cmp_via_cmpmem): Take ctz of len.  Obey
-finline-stringops.
(emit_block_cmp_via_loop): New.
* expr.h (emit_block_move): Add ctz of len defaulting to zero.
(emit_block_move_hints): Likewise.
(emit_block_cmp_hints): Likewise.
* builtins.cc (expand_builtin_memory_copy_args): Pass ctz of
len to emit_block_move_hints.
(try_store_by_multiple_pieces): Support starting with a loop.
(expand_builtin_memcmp): Pass ctz of len to
emit_block_cmp_hints.
(expand_builtin): Allow inline expansion of memset, memcpy,
memmove and memcmp if requested.
* common.opt (finline-stringops): New.
(ilsop_fn): New enum.
* flag-types.h (enum ilsop_fn): New.
* doc/invoke.texi (-finline-stringops): Add.

for  gcc/testsuite/ChangeLog

* gcc.dg/torture/inline-mem-cmp-1.c: New.
* gcc.dg/torture/inline-mem-cpy-1.c: New.
* gcc.dg/torture/inline-mem-cpy-cmp-1.c: New.
* gcc.dg/torture/inline-mem-move-1.c: New.
* gcc.dg/torture/inline-mem-set-1.c: New.
---
 gcc/builtins.cc|  114 ++
 gcc/common.opt |   34 ++
 gcc/doc/invoke.texi|   15 +
 gcc/expr.cc|  374 +++-
 gcc/expr.h |9 
 gcc/flag-types.h   |   11 +
 gcc/testsuite/gcc.dg/torture/inline-mem-cmp-1.c|7 
 gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c|8 
 .../gcc.dg/torture/inline-mem-cpy-cmp-1.c  |   11 +
 gcc/testsuite/gcc.dg/torture/inline-mem-move-1.c   |9 
 gcc/testsuite/gcc.dg/torture/inline-mem-set-1.c|   84 
 11 files changed, 646 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/inline-mem-cmp-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inline-mem-cpy-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inline-mem-cpy-cmp-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inline-mem-move-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/inline-mem-set-1.c

diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 8400adaf5b4db..1beaa4eae97a5 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -3769,7 +3769,7 @@ expand_builtin_memory_copy_args (tree dest, tree src, 
tree len,
 expected_align, expected_size,
 min_size, max_size, probable_max_size,
 use_mempcpy_call, _move_done,
-might_overlap);
+might_overlap, tree_ctz (len));
 
   /* Bail 

Re: [PATCH] libstdc++: Correct NTTP and simd_mask ctor call

[Alexandre Oliva via Gcc-patches]

On Jun  2, 2023, Matthias Kretz  wrote:

> I'm looking at that function again, also in light of recent improvements wrt. 
> code-gen, and will remove that assumption, that long long is vectorizable.

Thanks, I'll leave that to you, then.


I also noticed the same test is failing on rtems6 (at least with gcc
11).  AFAICT the problem is that _GLIBCXX_SIMD_MATH_CALL* macros in
simd_math.h expect the named functions to be in std::, but I get such
errors as:

.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1299: 
error: 'remainder' is not a member of 'std'
.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1299: note: 
suggested alternatives:
[...]
.../aarch64-rtems6/include/math.h:346: note:   'remainder'
[...]
.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1299: note: 
  'std::experimental::parallelism_v2::remainder'
.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1299: 
error: template argument 1 is invalid
[...]
.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1328: 
error: 'fmin' is not a member of 'std'; did you mean 'min'?
.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1328: 
error: 'fmin' is not a member of 'std'; did you mean 'min'?
.../aarch64-rtems6/include/c++/11.4.1/experimental/bits/simd_math.h:1328: 
error: template argument 1 is invalid

ISTM that rtems is missing some of the math.h functions expected by
libstdc++, but also that even those that are present are not visible in
namespace ::std::, where the macros reasonably expect to find them.  Is
this known?  Should I file a PR about it?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] libstdc++: Correct NTTP and simd_mask ctor call

[Alexandre Oliva via Gcc-patches]

Hello, Matthias,

On May 26, 2023, Matthias Kretz via Libstdc++  wrote:

> OK for master and all backports (after 11.4 is done)?
> tested on powerpc64le-linux-gnu and x86_64-pc-linux-gnu

>   * testsuite/experimental/simd/pr109822_cast_functions.cc: New
>   test.

This testcase fails to compile on PowerPC targets without VSX: 64-bit
integer and floating-point types cannot be vectorized.

I wonder if the test is malformed (and should be amended to test for
available simd types), or whether a patch like this would be desirable
to make simd constructs more portable.  I'm not sure about the
requirements.


[libstdc++] [simd] [ppc] use nonvector intrinsic fallback types

From: Alexandre Oliva 

Compiling such tests as pr109822_cast_functions.cc on powerpc targets
that don't support VSX fails because some intrinsic types that are
expected to be vectorizable are not defined without VSX.

Introduce fallback non-vector types to enable the code to compile.


for  libstdc++-v3/ChangeLog

* include/experimental/bits/simd.h: Introduce fallback
non-vector intrinsic_type_impl specializations for PowerPC
without VSX.
---
 libstdc++-v3/include/experimental/bits/simd.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/libstdc++-v3/include/experimental/bits/simd.h 
b/libstdc++-v3/include/experimental/bits/simd.h
index 834fe923065bd..2691823e869e8 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -2431,9 +2431,14 @@ template 
 #define _GLIBCXX_SIMD_PPC_INTRIN(_Tp)  
\
   template <>  
\
 struct __intrinsic_type_impl<_Tp> { using type = __vector _Tp; }
+#define _GLIBCXX_SIMD_PPC_INTRIN_NOVEC(_Tp)   \
+  template <>  
\
+struct __intrinsic_type_impl<_Tp> { using type = _Tp; }
 _GLIBCXX_SIMD_PPC_INTRIN(float);
 #ifdef __VSX__
 _GLIBCXX_SIMD_PPC_INTRIN(double);
+#else
+_GLIBCXX_SIMD_PPC_INTRIN_NOVEC(double);
 #endif
 _GLIBCXX_SIMD_PPC_INTRIN(signed char);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned char);
@@ -2444,12 +2449,19 @@ _GLIBCXX_SIMD_PPC_INTRIN(unsigned int);
 #if defined __VSX__ || __SIZEOF_LONG__ == 4
 _GLIBCXX_SIMD_PPC_INTRIN(signed long);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned long);
+#else
+_GLIBCXX_SIMD_PPC_INTRIN_NOVEC(signed long);
+_GLIBCXX_SIMD_PPC_INTRIN_NOVEC(unsigned long);
 #endif
 #ifdef __VSX__
 _GLIBCXX_SIMD_PPC_INTRIN(signed long long);
 _GLIBCXX_SIMD_PPC_INTRIN(unsigned long long);
+#else
+_GLIBCXX_SIMD_PPC_INTRIN_NOVEC(signed long long);
+_GLIBCXX_SIMD_PPC_INTRIN_NOVEC(unsigned long long);
 #endif
 #undef _GLIBCXX_SIMD_PPC_INTRIN
+#undef _GLIBCXX_SIMD_PPC_INTRIN_NOVEC
 
 template 
   struct __intrinsic_type<_Tp, _Bytes, enable_if_t<__is_vectorizable_v<_Tp> && 
_Bytes <= 16>>


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

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

[Alexandre Oliva via Gcc-patches]

When long double is wider than double, but from_chars is implemented
in terms of double, tests that involve the full precision of long
double are expected to fail.  Mark them as such on x86_64-*-vxworks*.

Tested on x86_64-vxworks7r2 with gcc-12.  Ok to install?


for  libstdc++-v3/ChangeLog

* testsuite/20_util/from_chars/4.cc: Skip long double test06
on x86_64-vxworks.
* testsuite/20_util/to_chars/long_double.cc: Xfail run on
x86_64-vxworks.
---
 libstdc++-v3/testsuite/20_util/from_chars/4.cc |2 +-
 .../testsuite/20_util/to_chars/long_double.cc  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/4.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
index c3594f9014bd3..63a32b511be4e 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/4.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
@@ -18,7 +18,7 @@
 //  is supported in C++14 as a GNU extension
 // { dg-do run { target c++14 } }
 // { dg-add-options ieee }
-// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* } }
+// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* 
x86_64-*-vxworks* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc 
b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
index 08363d9d04003..df02dff935f40 100644
--- a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
+++ b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
@@ -36,7 +36,7 @@
 
 // On systems that use double-precision from_chars for long double,
 // this is expected to fail.
-// { dg-xfail-run-if "from_chars limited to double-precision" { 
aarch64-*-vxworks* i*86-*-vxworks* } }
+// { dg-xfail-run-if "from_chars limited to double-precision" { 
aarch64-*-vxworks* i*86-*-vxworks* x86_64-*-vxworks* } }
 
 // { dg-require-effective-target ieee_floats }
 // { dg-require-effective-target size32plus }


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

[Alexandre Oliva via Gcc-patches]

On May 25, 2023, Segher Boessenkool  wrote:

> Fwiw, updating the insn counts blindly like this

... is a claim that carries a wildly incorrect and insulting underlying
assumption: I've actually identified the corresponding change to the
lp64 tests, compared the effects of the codegen changes, and concluded
the tests needed this changing for ilp32 to keep on testing for the same
thing after code changes brought about by changes that AFAICT had been
well understood when making the lp64 adjustments.

> If it is not possible to keep these tests up-to-date easily

The counts have been stable for a couple of release cycles already.

The change that caused the codegen differences is identified and
understood; the PR confirmed my findings, naming the root cause and the
incomplete testsuite adjustment.

I suspect there may also be ABI-related assumptions implied by the 'add'
counts, but I don't know enough about all the ppc variants to be sure.


Now, if your implied claim is correct that counting 'add/addi'
instructions in these tests is fragile, dropping the checks for those
would probably be best.  But if ppc maintainers seem to have different
opinions as to how to deal with the fallout of that one-time codegen
change, it would be foolish for me to get pulled into the cross fire.

Here's the patch that corrects the long-broken counts, with the
requested adjustments, retested with ppc- and ppc64-vx7r2.  Ok?


[testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

Codegen changes caused add instruction count mismatches on
ppc-*-linux-gnu and other 32-bit ppc targets.  At some point the
expected counts were adjusted for lp64, but ilp32 differences
remained, and published test results confirm it.


for  gcc/testsuite/ChangeLog

PR testsuite/101169
* gcc.target/powerpc/fold-vec-extract-char.p7.c: Adjust addi
counts for ilp32.
* gcc.target/powerpc/fold-vec-extract-double.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-float.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-float.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise.
---
 .../gcc.target/powerpc/fold-vec-extract-char.p7.c  |3 ++-
 .../powerpc/fold-vec-extract-double.p7.c   |3 +--
 .../gcc.target/powerpc/fold-vec-extract-float.p7.c |3 +--
 .../gcc.target/powerpc/fold-vec-extract-float.p8.c |2 +-
 .../gcc.target/powerpc/fold-vec-extract-int.p7.c   |3 +--
 .../gcc.target/powerpc/fold-vec-extract-int.p8.c   |2 +-
 .../gcc.target/powerpc/fold-vec-extract-short.p7.c |3 +--
 .../gcc.target/powerpc/fold-vec-extract-short.p8.c |2 +-
 8 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
index 29a8aa84db282..c6647431d09c9 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
@@ -11,7 +11,8 @@
 /* one extsb (extend sign-bit) instruction generated for each test against
unsigned types */
 
-/* { dg-final { scan-assembler-times {\maddi\M} 9 } } */
+/* { dg-final { scan-assembler-times {\maddi\M} 9 { target { lp64 } } } } */
+/* { dg-final { scan-assembler-times {\maddi\M} 6 { target { ilp32 } } } } */
 /* { dg-final { scan-assembler-times {\mli\M} 6 } } */
 /* { dg-final { scan-assembler-times {\mstxvw4x\M|\mstvx\M|\mstxv\M} 6 } } */
 /* -m32 target uses rlwinm in place of rldicl. */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
index 3cae644b90b71..cbf6cffbeba17 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
@@ -13,8 +13,7 @@
 /* { dg-final { scan-assembler-times {\mxxpermdi\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mli\M} 1 } } */
 /* -m32 target has an 'add' in place of one of the 'addi'. */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } } 
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } } 
*/
+/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 } } */
 /* -m32 target has a rlwinm in place of a rldic .  */
 /* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
index 59a4979457dcb..c9abb6c1f352c 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
@@ -12,8 

Re: [PATCH] [x86] reenable dword MOVE_MAX for better memmove inlining

[Alexandre Oliva via Gcc-patches]

On May 25, 2023, Richard Biener  wrote:

> On Thu, May 25, 2023 at 1:10 PM Alexandre Oliva  wrote:
>> 
>> On May 25, 2023, Richard Biener  wrote:
>> 
>> > I mean we could do what RTL expansion would do later and do
>> > by-pieces, thus emit multiple loads/stores but not n loads and then
>> > n stores but interleaved.
>> 
>> That wouldn't help e.g. gcc.dg/memcpy-6.c's fold_move_8, because
>> MOVE_MAX and MOVE_MAX_PIECES currently limits inline expansion to 4
>> bytes on x86 without SSE, both in gimple and RTL, and interleaved loads
>> and stores wouldn't help with memmove.  We can't fix that by changing
>> code that uses MOVE_MAX and/or MOVE_MAX_PIECES, when these limits are
>> set too low.

> Btw, there was a short period where the MOVE_MAX limit was restricted
> but that had fallout and we've reverted since then.

Erhm...  Are we even talking about the same issue?

i386/i386.h reduced the 32-bit non-SSE MOVE_MAX from 16 to 4, which
broke this test; I'm proposing to bounce it back up to 8, so that we get
a little more memmove inlining, enough for tests that expect that much
to pass.

You may be focusing on the gimple-fold bit, because I mentioned it, but
even the rtl expander is failing to expand the memmove because of the
setting, as evidenced by the test's failure in the scan for memmove in
the final dump.

That MOVE_MAX change was a significant regression in codegen for 32-bit
non-SSE x86, and I'm proposing to fix that.  Compensating for that
regression elsewhere doesn't seem desirable to me: MOVE_MAX can be much
higher even on other x86 variants, so the effects of such attempts may
harm quite significantly more modern CPUs.

Conversely, I don't expect the reduction of MOVE_MAX on SSE-less x86 a
couple of years ago to have been measured for performance effects, given
the little overall relevance of such CPUs, and the very visible and
undesirable effects on codegen that change brought onto them.  And yet,
I'm being very conservative in the proposed reversion, because
benchmarking such targets in any meaningful way would be somewhat
challenging for myself as well.

So, could we please have this narrow fix of this limited regression at
the spot where it was introduced accepted, rather than debating
tangents?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [x86] reenable dword MOVE_MAX for better memmove inlining

[Alexandre Oliva via Gcc-patches]

On May 25, 2023, Richard Biener  wrote:

> I mean we could do what RTL expansion would do later and do
> by-pieces, thus emit multiple loads/stores but not n loads and then
> n stores but interleaved.

That wouldn't help e.g. gcc.dg/memcpy-6.c's fold_move_8, because
MOVE_MAX and MOVE_MAX_PIECES currently limits inline expansion to 4
bytes on x86 without SSE, both in gimple and RTL, and interleaved loads
and stores wouldn't help with memmove.  We can't fix that by changing
code that uses MOVE_MAX and/or MOVE_MAX_PIECES, when these limits are
set too low.

I'm also concerned that doing more such expansion in gimple folding
would be reversed in later gimple passes.  That's good in that it would
enable efficient rtl movmem/cpymem instruction selection, but it's not
clear to me that there would generally be benefits to such early
open-coding in gimple.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

[Alexandre Oliva via Gcc-patches]

On May 25, 2023, "Kewen.Lin"  wrote:

> Thanks for fixing, I tested this on ppc64le and ppc64 {-m64,-m32}
> well.

Thanks!

> I think this is for PR101169, could you add it as PR marker?

Nice, will do!

>> -/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } 
>> } } */
>> +/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target ilp32 } 
>> } } */

> So both lp64 and ilp32 have the same count, could we merge it and
> remove the selectors?

We could, but...  I thought I wouldn't, since they were different
before, and they're likely to diverge again in the future.  I thought
that combining them might suggest that they ought to be the same, when
we already know that this is not the case.

I'll prepare an alternate patch that combines them.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [x86] reenable dword MOVE_MAX for better memmove inlining

[Alexandre Oliva via Gcc-patches]

--text follows this line--
On May 24, 2023, Richard Biener  wrote:

> gimple_fold_builtin_memory_op tries to expand the call to a single
> load plus a single store so we can handle overlaps by first loading
> everything to registers and then storing:

*nod*, that's why I figured we could afford to go back to allowing
DImode (with -m32) or TImode (with -m64) even without vector modes: we'd
just use a pair of registers, a single insn, even though not a single
hardware instruction.

> using DImode on i?86 without SSE means we eventually perform two
> loads and two stores which means we need two registers available.

*nod*.  But the alternative is to issue an out-of-line call to memmove,
which would clobber more than 2 registers.  ISTM that inlining such
calls is better, whether optimizing for speed or size.

> So I think if we want to expand this further at the GIMPLE level we
> should still honor MOVE_MAX but eventually emit multiple loads/stores
> honoring the MOVE_MAX_PIECES set of constraints there and avoid
> expanding to sequences where we cannot interleave the loads/stores
> (aka for the memmove case).

But...  don't we already?  If I'm reading the code right, we'll already
issue gimple code to load the whole block into a temporary and then
store it, but current MOVE_MAX won't let us go past 4 bytes on SSE-less
x86.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

[Alexandre Oliva via Gcc-patches]

Codegen changes caused add instruction count mismatches on
ppc-*-linux-gnu and other 32-bit ppc targets.  At some point the
expected counts were adjusted for lp64, but ilp32 differences
remained, and published test results confirm it.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/fold-vec-extract-char.p7.c: Adjust addi
counts for ilp32.
* gcc.target/powerpc/fold-vec-extract-double.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-float.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-float.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise.
---
 .../gcc.target/powerpc/fold-vec-extract-char.p7.c  |3 ++-
 .../powerpc/fold-vec-extract-double.p7.c   |2 +-
 .../gcc.target/powerpc/fold-vec-extract-float.p7.c |2 +-
 .../gcc.target/powerpc/fold-vec-extract-float.p8.c |2 +-
 .../gcc.target/powerpc/fold-vec-extract-int.p7.c   |2 +-
 .../gcc.target/powerpc/fold-vec-extract-int.p8.c   |2 +-
 .../gcc.target/powerpc/fold-vec-extract-short.p7.c |2 +-
 .../gcc.target/powerpc/fold-vec-extract-short.p8.c |2 +-
 8 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
index 29a8aa84db282..c6647431d09c9 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p7.c
@@ -11,7 +11,8 @@
 /* one extsb (extend sign-bit) instruction generated for each test against
unsigned types */
 
-/* { dg-final { scan-assembler-times {\maddi\M} 9 } } */
+/* { dg-final { scan-assembler-times {\maddi\M} 9 { target { lp64 } } } } */
+/* { dg-final { scan-assembler-times {\maddi\M} 6 { target { ilp32 } } } } */
 /* { dg-final { scan-assembler-times {\mli\M} 6 } } */
 /* { dg-final { scan-assembler-times {\mstxvw4x\M|\mstvx\M|\mstxv\M} 6 } } */
 /* -m32 target uses rlwinm in place of rldicl. */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
index 3cae644b90b71..db325efbb07ff 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
@@ -14,7 +14,7 @@
 /* { dg-final { scan-assembler-times {\mli\M} 1 } } */
 /* -m32 target has an 'add' in place of one of the 'addi'. */
 /* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } } 
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } } 
*/
+/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target ilp32 } } } 
*/
 /* -m32 target has a rlwinm in place of a rldic .  */
 /* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
index 59a4979457dcb..42ec69475fd07 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
@@ -13,7 +13,7 @@
 /* { dg-final { scan-assembler-times {\mli\M} 1 } } */
 /* -m32 as an add in place of an addi. */
 /* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } } 
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } } 
*/
+/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target ilp32 } } } 
*/
 /* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstvx\M|\mstxv\M} 1 } } */
 /* -m32 uses rlwinm in place of rldic */
 /* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
index 4b1d75ee26d0f..68de4b307 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
@@ -26,7 +26,7 @@
 /* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 { target ilp32 } } } */
 /* { dg-final { scan-assembler-times {\madd\M} 1 { target ilp32 } } } */
 /* { dg-final { scan-assembler-times {\mlfs\M} 1 { target ilp32 } } } */
-/* { dg-final { scan-assembler-times {\maddi\M} 2 { target ilp32 } } } */
+/* { dg-final { scan-assembler-times {\maddi\M} 1 { target ilp32 } } } */
 
 
 #include 
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p7.c
index 3729a1646e9c9..e8130693ee953 100644
--- 

[PATCH] [libstdc++] [testsuite] xfail to_chars/long_double on x86-vxworks

[Alexandre Oliva via Gcc-patches]

Just as on aarch64, x86's wider long double experiences loss of
precision with from_chars implemented in terms of double.  Expect the
execution fail.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  libstdc++-v3/ChangeLog

* testsuite/20_util/to_chars/long_double.cc: Expect execution
fail on x86-vxworks.
---
 .../testsuite/20_util/to_chars/long_double.cc  |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc 
b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
index 263144bd42cba..08363d9d04003 100644
--- a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
+++ b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
@@ -36,7 +36,7 @@
 
 // On systems that use double-precision from_chars for long double,
 // this is expected to fail.
-// { dg-xfail-run-if "from_chars limited to double-precision" { 
aarch64-*-vxworks* } }
+// { dg-xfail-run-if "from_chars limited to double-precision" { 
aarch64-*-vxworks* i*86-*-vxworks* } }
 
 // { dg-require-effective-target ieee_floats }
 // { dg-require-effective-target size32plus }

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] [x86] cope with --enable-frame-pointer

[Alexandre Oliva via Gcc-patches]

Various x86 tests fail if the toolchain is configured with
--enable-frame-pointer, because the unexpected extra insns mess with
the expected asm counts.  Add -fomit-frame-pointer so that they can
still pass.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

* gcc.target/i386/pieces-memcpy-7.c: Add -fomit-frame-pointer.
* gcc.target/i386/pieces-memcpy-8.c: Likewise.
* gcc.target/i386/pieces-memcpy-9.c: Likewise.
* gcc.target/i386/pieces-memset-1.c: Likewise.
* gcc.target/i386/pieces-memset-36.c: Likewise.
* gcc.target/i386/pieces-memset-4.c: Likewise.
* gcc.target/i386/pieces-memset-40.c: Likewise.
* gcc.target/i386/pieces-memset-41.c: Likewise.
* gcc.target/i386/pieces-memset-7.c: Likewise.
* gcc.target/i386/pieces-memset-8.c: Likewise.
* gcc.target/i386/pieces-memset-9.c: Likewise.
* gcc.target/i386/pr102230.c: Likewise.
* gcc.target/i386/pr78103-2.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/pieces-memcpy-7.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memcpy-8.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memcpy-9.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-1.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-36.c |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-4.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-40.c |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-41.c |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-7.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-8.c  |2 ++
 gcc/testsuite/gcc.target/i386/pieces-memset-9.c  |2 ++
 gcc/testsuite/gcc.target/i386/pr102230.c |2 ++
 gcc/testsuite/gcc.target/i386/pr78103-2.c|2 ++
 13 files changed, 26 insertions(+)

diff --git a/gcc/testsuite/gcc.target/i386/pieces-memcpy-7.c 
b/gcc/testsuite/gcc.target/i386/pieces-memcpy-7.c
index 3d248d447ea42..64fd8b4176cec 100644
--- a/gcc/testsuite/gcc.target/i386/pieces-memcpy-7.c
+++ b/gcc/testsuite/gcc.target/i386/pieces-memcpy-7.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mno-avx -msse2 -mtune=generic" } */
+/* Cope with --enable-frame-pointer.  */
+/* { dg-additional-options "-fomit-frame-pointer" } */
 
 void
 foo (int a1, int a2, int a3, int a4, int a5, int a6, char *dst, char *src)
diff --git a/gcc/testsuite/gcc.target/i386/pieces-memcpy-8.c 
b/gcc/testsuite/gcc.target/i386/pieces-memcpy-8.c
index c13a2beb2f017..fc60c46c58900 100644
--- a/gcc/testsuite/gcc.target/i386/pieces-memcpy-8.c
+++ b/gcc/testsuite/gcc.target/i386/pieces-memcpy-8.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mno-avx2 -mavx -mtune=generic" } */
+/* Cope with --enable-frame-pointer.  */
+/* { dg-additional-options "-fomit-frame-pointer" } */
 
 void
 foo (int a1, int a2, int a3, int a4, int a5, int a6, char *dst, char *src)
diff --git a/gcc/testsuite/gcc.target/i386/pieces-memcpy-9.c 
b/gcc/testsuite/gcc.target/i386/pieces-memcpy-9.c
index 238f88b275eb7..62fcb6f569204 100644
--- a/gcc/testsuite/gcc.target/i386/pieces-memcpy-9.c
+++ b/gcc/testsuite/gcc.target/i386/pieces-memcpy-9.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mavx512f -mtune=generic" } */
+/* Cope with --enable-frame-pointer.  */
+/* { dg-additional-options "-fomit-frame-pointer" } */
 
 void
 foo (int a1, int a2, int a3, int a4, int a5, int a6, char *dst, char *src)
diff --git a/gcc/testsuite/gcc.target/i386/pieces-memset-1.c 
b/gcc/testsuite/gcc.target/i386/pieces-memset-1.c
index f7487ba9c5b28..0002c6838ab76 100644
--- a/gcc/testsuite/gcc.target/i386/pieces-memset-1.c
+++ b/gcc/testsuite/gcc.target/i386/pieces-memset-1.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mno-avx -msse2 -mtune=generic -mno-stackrealign" } */
+/* Cope with --enable-frame-pointer.  */
+/* { dg-additional-options "-fomit-frame-pointer" } */
 
 extern char *dst;
 
diff --git a/gcc/testsuite/gcc.target/i386/pieces-memset-36.c 
b/gcc/testsuite/gcc.target/i386/pieces-memset-36.c
index d1f1263c7b211..d1bbfa204a7f8 100644
--- a/gcc/testsuite/gcc.target/i386/pieces-memset-36.c
+++ b/gcc/testsuite/gcc.target/i386/pieces-memset-36.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mno-avx512f -mavx2 -mtune=generic" } */
+/* Cope with --enable-frame-pointer.  */
+/* { dg-additional-options "-fomit-frame-pointer" } */
 
 extern char *dst;
 
diff --git a/gcc/testsuite/gcc.target/i386/pieces-memset-4.c 
b/gcc/testsuite/gcc.target/i386/pieces-memset-4.c
index a12b9dda28bd3..8b3f3b00214f8 100644
--- a/gcc/testsuite/gcc.target/i386/pieces-memset-4.c
+++ b/gcc/testsuite/gcc.target/i386/pieces-memset-4.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mno-avx -msse2 -mtune=generic -mno-stackrealign" } */
+/* Cope with --enable-frame-pointer.  */
+/* { dg-additional-options "-fomit-frame-pointer" } */
 
 extern char *dst;
 
diff --git 

[PATCH] [x86] reenable dword MOVE_MAX for better memmove inlining

[Alexandre Oliva via Gcc-patches]

MOVE_MAX on x86* used to accept up to 16 bytes, even without SSE,
which enabled inlining of small memmove by loading and then storing
the entire range.  After the "x86: Update piecewise move and store"
r12-2666 change, memmove of more than 4 bytes would not be inlined in
gimple_fold_bultin_memory_op, failing the expectations of a few tests.

I can see how lowering it for MOVE_MAX_PIECES can get us better
codegen decisions overall, but surely inlining memmove with 2 32-bit
loads and stores is better than an outline call that requires setting
up 3 arguments.  I suppose even 3 or 4 could do better.  But maybe it
is gimple_fold_builtin_memory_op that needs tweaking?

Anyhow, this patch raises MOVE_MAX back a little for non-SSE targets,
while preserving the new value for MOVE_MAX_PIECES.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for gcc/ChangeLog

* config/i386/i386.h (MOVE_MAX): Rename to...
(MOVE_MAX_VEC): ... this.  Add NONVEC parameter, and use it as
the last resort, instead of UNITS_PER_WORD.
(MOVE_MAX): Reintroduce in terms of MOVE_MAX_VEC, with
2*UNITS_PER_WORD.
(MOVE_MAX_PIECES): Likewise, but with UNITS_PER_WORD.
---
 gcc/config/i386/i386.h |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index c7439f89bdf92..5293a332a969a 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1801,7 +1801,9 @@ typedef struct ix86_args {
is the number of bytes at a time which we can move efficiently.
MOVE_MAX_PIECES defaults to MOVE_MAX.  */
 
-#define MOVE_MAX \
+#define MOVE_MAX MOVE_MAX_VEC (2 * UNITS_PER_WORD)
+#define MOVE_MAX_PIECES MOVE_MAX_VEC (UNITS_PER_WORD)
+#define MOVE_MAX_VEC(NONVEC) \
   ((TARGET_AVX512F \
 && (ix86_move_max == PVW_AVX512 \
|| ix86_store_max == PVW_AVX512)) \
@@ -1813,7 +1815,7 @@ typedef struct ix86_args {
   : ((TARGET_SSE2 \
  && TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
  && TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
-? 16 : UNITS_PER_WORD)))
+? 16 : (NONVEC
 
 /* STORE_MAX_PIECES is the number of bytes at a time that we can store
efficiently.  Allow 16/32/64 bytes only if inter-unit move is enabled

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] [ppc] xfail uninit-pred-9_b bogus warn on ppc32 too

[Alexandre Oliva via Gcc-patches]

The bogus warning is present on 32-bit ppc-vx7r2 too, so drop the 64
from the powerpc xfail triplet.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

* gcc.dg/uninit-pred-9_b.c: Xfail bogus warning on 32-bit ppc
as well.
---
 gcc/testsuite/gcc.dg/uninit-pred-9_b.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c 
b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
index c8f427b12c0ab..0f508fa56e1c5 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
@@ -17,7 +17,7 @@ int foo (int n, int l, int m, int r)
 
   if (l > 100)
 if ( (n <= 9) &&  (m < 100)  && (r < 19) )
-  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
powerpc64*-*-* cris-*-* riscv*-*-* } } */
+  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
powerpc*-*-* cris-*-* riscv*-*-* } } */
 
   if ( (n <= 8) &&  (m < 99)  && (r < 19) )
   blah(v); /* { dg-bogus "uninitialized" "pr101674" { xfail mmix-*-* } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required

[Alexandre Oliva via Gcc-patches]

On May  5, 2022, Alexandre Oliva  wrote:

> for  gcc/ChangeLog

>   PR target/100106
>   * emit-rtl.cc (validate_subreg): Reject a SUBREG of a MEM that
>   requires stricter alignment than MEM's.

> for  gcc/testsuite/ChangeLog

>   PR target/100106
>   * gcc.target/powerpc/pr100106-sa.c: New.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594166.html

The testcase variant was approved, but the reformatted patch is still
pending review, despite support from Vlad Makarov for the original one;
the suggested separate followup patch, mentioned in the linked email,
turned out to be far more involved than anticipated, and needs further
work, but it's independent from this self-contained fix.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] [i386] enable sse2 for signbit-2.c

[Alexandre Oliva via Gcc-patches]

The expected results for signbit-2 only arise on x86 with avx512f
disabled and sse2 enabled.  The patch already disables avx512f
explicitly, but it fails to enable sse2.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

* gcc.dg/signbit-2.c: Add -msse2 on x86.
---
 gcc/testsuite/gcc.dg/signbit-2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index d7b406effc62d..62bb4047d7421 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -2,7 +2,7 @@
 /* { dg-options "-O3 -fdump-tree-optimized" } */
 
 /* This test does not work when the truth type does not match vector type.  */
-/* { dg-additional-options "-mno-avx512f" { target { i?86-*-* x86_64-*-* } } } 
*/
+/* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-* 
x86_64-*-* } } } */
 /* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
 /* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
 /* { dg-skip-if "no fallback for MVE" { arm_mve } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] require profiling for -pg

[Alexandre Oliva via Gcc-patches]

Fix two tests that use -pg but don't declare their requirement for
profiling support.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

* gcc.target/i386/mcount_pic.c: Add dg-require-profiling.
* gcc.target/i386/pr104447: Likewise.
---
 gcc/testsuite/gcc.target/i386/mcount_pic.c |1 +
 gcc/testsuite/gcc.target/i386/pr104447.c   |1 +
 2 files changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.target/i386/mcount_pic.c 
b/gcc/testsuite/gcc.target/i386/mcount_pic.c
index 5546933d1946d..732be66b7b33d 100644
--- a/gcc/testsuite/gcc.target/i386/mcount_pic.c
+++ b/gcc/testsuite/gcc.target/i386/mcount_pic.c
@@ -3,6 +3,7 @@
 /* { dg-do run } */
 /* { dg-require-effective-target fpic } */
 /* { dg-require-effective-target ia32 } */
+/* { dg-require-profiling "-pg" } */
 /* { dg-options "-O2 -fpic -pg -save-temps" } */
 
 int main ()
diff --git a/gcc/testsuite/gcc.target/i386/pr104447.c 
b/gcc/testsuite/gcc.target/i386/pr104447.c
index bf11e8696e68f..cb618c7b8bb32 100644
--- a/gcc/testsuite/gcc.target/i386/pr104447.c
+++ b/gcc/testsuite/gcc.target/i386/pr104447.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-profiling "-pg" } */
 /* { dg-options "-O2 -pg" } */
 
 int

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] require pthread for openmp

[Alexandre Oliva via Gcc-patches]

Fix test that uses -fopenmp without declaring requirement for pthread
support.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

* g++.dg/pr80481.C: Add explicit pthread requirement.
---
 gcc/testsuite/g++.dg/pr80481.C |2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/g++.dg/pr80481.C b/gcc/testsuite/g++.dg/pr80481.C
index 78c463b8e3b58..3a8869914634f 100644
--- a/gcc/testsuite/g++.dg/pr80481.C
+++ b/gcc/testsuite/g++.dg/pr80481.C
@@ -1,4 +1,6 @@
 // { dg-do compile { target { i?86-*-* x86_64-*-* }  && { ! *-*-solaris* } } }
+// -fopenmp implies -pthread
+// { dg-require-effective-target pthread } 
 // { dg-options "-Ofast -funroll-loops -fopenmp -march=knl" }
 // Disabling epilogues until we find a better way to deal with scans.
 // { dg-additional-options "--param vect-epilogues-nomask=0" }

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] require pic for pr103074.c

[Alexandre Oliva via Gcc-patches]

Fix test that uses -fPIC without stating the requirement for PIC
support.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.

for  gcc/testsuite/ChangeLog

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

diff --git a/gcc/testsuite/gcc.target/i386/pr103074.c 
b/gcc/testsuite/gcc.target/i386/pr103074.c
index 276ad82a1de1e..668d9531096dc 100644
--- a/gcc/testsuite/gcc.target/i386/pr103074.c
+++ b/gcc/testsuite/gcc.target/i386/pr103074.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
 /* { dg-options "-march=bonnell -Os -fPIC -fschedule-insns -w" } */
 
 void

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] tsvc: skip include malloc.h when unavailable

[Alexandre Oliva via Gcc-patches]

tsvc tests all fail on systems that don't offer a malloc.h, other than
those that explicitly rule that out.  Use the preprocessor to test for
malloc.h's availability.

tsvc.h also expects a definition for struct timeval, but it doesn't
include sys/time.h.  Add a conditional include thereof.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/tsvc/tsvc.h: Test for and conditionally include
malloc.h and sys/time.h.

---
 gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h 
b/gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h
index 75494c24cfa62..cd39c041903dd 100644
--- a/gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h
+++ b/gcc/testsuite/gcc.dg/vect/tsvc/tsvc.h
@@ -11,9 +11,12 @@
 
 #include 
 #include 
-#if !defined(__APPLE__) && !defined(__DragonFly__)
+#if __has_include()
 #include 
 #endif
+#if __has_include()
+#include 
+#endif
 #include 
 #include 
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] Check for sysconf decl on vxworks

[Alexandre Oliva via Gcc-patches]

The sysconf function is only available in rtp mode on vxworks.  In
kernel mode, it is not even declared, but the feature test macro in
the testsuite doesn't notice its absence because it's a link test, and
vxworks kernel mode uses partial linking.

This patch introduces an alternate test on vxworks targets to check
for a declaration and for an often-used sysconf parameter.

Bootstrapped on x86_64-linux-gnu.  Also tested on ppc- and x86-vx7r2
with gcc-12.


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (check_effective_target_sysconf):
Check for declaration and _SC_PAGESIZE on vxworks.
---
 gcc/testsuite/lib/target-supports.exp |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index bd9f432e4a761..263ef35a2e4df 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1146,6 +1146,17 @@ proc check_effective_target_mmap {} {
 # Return 1 if the target supports sysconf, 0 otherwise.
 
 proc check_effective_target_sysconf {} {
+# VxWorks has sysconf in rtp mode only, but our way to test can't
+# tell kernel mode doesn't, as we're doing partial links for
+# kernel modules.  We can tell by checking for a declaration, or
+# for some sysconf parm, because configurations that don't offer
+# sysconf don't have either.
+if { [istarget *-*-vxworks*] } {
+   return [check_no_compiler_messages sysconfdecl assembly {
+   #include 
+   int f() { return sysconf(_SC_PAGESIZE); }
+   }];
+}
 return [check_function_available "sysconf"]
 }
 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] use strtold for from_chars even without locale

[Alexandre Oliva via Gcc-patches]

Here's a patch to skip/xfail the bits that are expected to fail on
aarch64-vxworks.


[libstdc++] [testsuite] xfail double-prec from_chars for ldbl

When long double is wider than double, but from_chars is implemented
in terms of double, tests that involve the full precision of long
double are expected to fail.  Mark them as such on aarch64-*-vxworks.


for  libstdc++-v3/ChangeLog

* testsuite/20_util/from_chars/4.cc: Skip long double test06
on aarch64-vxworks.
* testsuite/20_util/to_chars/long_double.cc: Xfail run on
aarch64-vxworks.
---
 libstdc++-v3/testsuite/20_util/from_chars/4.cc |3 ++-
 .../testsuite/20_util/to_chars/long_double.cc  |4 
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/4.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
index dd55690eb6511..c3594f9014bd3 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/4.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
@@ -18,6 +18,7 @@
 //  is supported in C++14 as a GNU extension
 // { dg-do run { target c++14 } }
 // { dg-add-options ieee }
+// { dg-additional-options "-DSKIP_LONG_DOUBLE" { target aarch64-*-vxworks* } }
 
 #include 
 #include 
@@ -354,7 +355,7 @@ test06()
 {
   test_max_mantissa();
   test_max_mantissa();
-#ifdef __GLIBCXX_TYPE_INT_N_0
+#if defined __GLIBCXX_TYPE_INT_N_0 && !defined SKIP_LONG_DOUBLE
   test_max_mantissa();
 #endif
 }
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc 
b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
index 880c98021876d..263144bd42cba 100644
--- a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
+++ b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
@@ -34,6 +34,10 @@
 // more portable and robust to differences in system printf behavior.
 // { dg-xfail-run-if "Non-conforming printf (see PR98384)" { *-*-solaris* 
*-*-darwin* } }
 
+// On systems that use double-precision from_chars for long double,
+// this is expected to fail.
+// { dg-xfail-run-if "from_chars limited to double-precision" { 
aarch64-*-vxworks* } }
+
 // { dg-require-effective-target ieee_floats }
 // { dg-require-effective-target size32plus }
 // { dg-require-cmath "" }


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] use strtold for from_chars even without locale

[Alexandre Oliva via Gcc-patches]

On May  4, 2023, Jonathan Wakely  wrote:

> And we could use strtod for a target that doesn't support locales *at all*
> (so strtod always behaves as specified for LANG=C).

Oh, sorry, I misread the *_USELOCALE macro as *_USE_LOCALE, and I
thought this was what I was doing.  Nevermind, patch withdrawn.

I guess I should look into how to xfail or skip the tests involving
full-precision long doubles on targets that are limited to doubles with
lower precision to convert chars to long doubles.  It's a pity to xfail
the whole tests over an expected issue.

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[vxworks] [testsuite] [aarch64] use builtin in pred-not-gen-4.c

[Alexandre Oliva via Gcc-patches]

On vxworks, isunordered is defined as a macro that ultimately calls a
_Fpcomp function, that GCC doesn't recognize as a builtin, so it
can't optimize accordingly.

Use __builtin_isunordered instead to get the desired code for the
test.

Regstrapped on x86_64-linux-gnu.  Also tested on aarch64-vx7r2 with
gcc-12.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/aarch64/pred-not-gen-4.c: Drop math.h include,
call builtin.
---
 .../gcc.target/aarch64/sve/pred-not-gen-4.c|4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pred-not-gen-4.c 
b/gcc/testsuite/gcc.target/aarch64/sve/pred-not-gen-4.c
index 0001dd3fc211f..1845bd3f0f704 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/pred-not-gen-4.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/pred-not-gen-4.c
@@ -1,12 +1,10 @@
 /* { dg-do compile } */
 /* { dg-options "-O3" } */
 
-#include 
-
 void f13(double * restrict z, double * restrict w, double * restrict x, double 
* restrict y, int n)
 {
 for (int i = 0; i < n; i++) {
-z[i] = (isunordered(w[i], 0)) ? x[i] + w[i] : y[i] - w[i];
+z[i] = (__builtin_isunordered(w[i], 0)) ? x[i] + w[i] : y[i] - w[i];
 }
 }
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[libstdc++] use strtold for from_chars even without locale

[Alexandre Oliva via Gcc-patches]

When we're using fast_float for 32- and 64-bit floating point, use
strtold for wider long double, even if locales are unavailable.

On vxworks, test for strtof's and strtold's declarations, so that they
can be used even when cross compiling.

Include stdlib.h in the decl-checking macro, so that it can find them.

Regstrapped on x86_64-linux-gnu.  Also tested on aarch64-vx7r2 with
gcc-12, where uselocale is not available, and using strtold rather than
fast_math's double fallback avoids a couple of from_chars-related
testsuite fails (from_chars/4.cc and to_chars/long_double.cc).  Ok to
install?


for  libstdc++-v3/ChangeLog

* src/c++17/floating_from_chars.cc
(USE_STRTOD_FOR_FROM_CHARS): Define when using fast_float if
long double is not as wide as double and strtold is not
broken.
* crossconfig.m4: Test for strtof and strtold declarations on
vxworks.
(GLIBCXX_CHECK_MATH_DECL): Include stdlib.h too.
* configure: Rebuilt.
---
 libstdc++-v3/configure|  131 +
 libstdc++-v3/crossconfig.m4   |3 -
 libstdc++-v3/src/c++17/floating_from_chars.cc |   10 ++
 3 files changed, 143 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
[omitted]
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index b3269cb88e077..9db32f4d422da 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -293,7 +293,7 @@ dnl # switch to more elaborate tests.
 GLIBCXX_CHECK_MATH_DECLS([
   acosl asinl atan2l atanl ceill cosl coshl expl fabsl floorl fmodl
   frexpl ldexpl log10l logl modfl powl sinl sinhl sqrtl tanl tanhl hypotl
-  ldexpf modff hypotf frexpf])
+  ldexpf modff hypotf frexpf strtof strtold])
 dnl # sincosl is the only one missing here, compared with the *l
 dnl # functions in the list guarded by
 dnl # long_double_math_on_this_cpu in configure.ac, right after
@@ -323,6 +323,7 @@ AC_DEFUN([GLIBCXX_CHECK_MATH_DECL], [
   AC_LANG_SAVE
   AC_LANG_C
   AC_TRY_COMPILE([
+#include 
 #include 
 #ifdef HAVE_IEEEFP_H
 # include 
diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc 
b/libstdc++-v3/src/c++17/floating_from_chars.cc
index 78b9d92cdc0fa..15af811d198c4 100644
--- a/libstdc++-v3/src/c++17/floating_from_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_from_chars.cc
@@ -80,6 +80,10 @@ extern "C" _Float128 __strtof128(const char*, char**)
 # if __LDBL_MANT_DIG__ == __DBL_MANT_DIG__
 // No need to use strtold.
 #  undef USE_STRTOD_FOR_FROM_CHARS
+# elif !defined USE_STRTOD_FOR_FROM_CHARS \
+   && defined _GLIBCXX_HAVE_STRTOLD && !defined 
_GLIBCXX_HAVE_BROKEN_STRTOLD
+// A working strtold will be more compliant than fast_float's double.
+#  define USE_STRTOD_FOR_FROM_CHARS 1
 # endif
 #endif
 
@@ -607,9 +611,11 @@ namespace
   ptrdiff_t
   from_chars_impl(const char* str, T& value, errc& ec) noexcept
   {
+#if _GLIBCXX_HAVE_USELOCALE
 if (locale_t loc = ::newlocale(LC_ALL_MASK, "C", (locale_t)0)) [[likely]]
   {
locale_t orig = ::uselocale(loc);
+#endif
 
 #if _GLIBCXX_USE_C99_FENV_TR1 && defined(FE_TONEAREST)
const int rounding = std::fegetround();
@@ -652,8 +658,10 @@ namespace
  std::fesetround(rounding);
 #endif
 
+#if _GLIBCXX_HAVE_USELOCALE
::uselocale(orig);
::freelocale(loc);
+#endif
 
const ptrdiff_t n = endptr - str;
if (conv_errno == ERANGE) [[unlikely]]
@@ -674,9 +682,11 @@ namespace
ec = errc();
  }
return n;
+#if _GLIBCXX_HAVE_USELOCALE
   }
 else if (errno == ENOMEM)
   ec = errc::not_enough_memory;
+#endif
 
 return 0;
   }


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[FYI] Use CONFIG_SHELL-/bin/sh in genmultilib

[Alexandre Oliva via Gcc-patches]

There are still shells on some systems that lack the ability to start
scripts when not using the shell name explicitly.  Adjust genmultilib
to use ${CONFIG_SHELL-/bin/sh} the same way configure does.

Regstrapped on x86_64-linux-gnu.  Also built riscv64-elf on an affected
platform.  I'm checking this in.


for  gcc/ChangeLog

* genmultilib: Use CONFIG_SHELL to run sub-scripts.
---
 gcc/genmultilib |   30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/gcc/genmultilib b/gcc/genmultilib
index f8bd90b116cd1..6683c3490266f 100644
--- a/gcc/genmultilib
+++ b/gcc/genmultilib
@@ -170,23 +170,23 @@ if [ "$#" != "0" ]; then
 all=${initial}`echo $first | sed -e 's_|_/_'g`
 first=`echo $first | sed -e 's_|_ _'g`
 echo ${all}/
-initial="${initial}${all}/" ./tmpmultilib $@
-./tmpmultilib $first $@ | grep -v "^${all}"
+initial="${initial}${all}/" ${CONFIG_SHELL-/bin/sh} ./tmpmultilib $@
+${CONFIG_SHELL-/bin/sh} ./tmpmultilib $first $@ | grep -v "^${all}"
 ;;
   *)
 for opt in `echo $first | sed -e 's|/| |'g`; do
   echo ${initial}${opt}/
 done
-./tmpmultilib $@
+${CONFIG_SHELL-/bin/sh} ./tmpmultilib $@
 for opt in `echo $first | sed -e 's|/| |'g`; do
-  initial="${initial}${opt}/" ./tmpmultilib $@
+  initial="${initial}${opt}/" ${CONFIG_SHELL-/bin/sh} ./tmpmultilib $@
 done
   esac
 fi
 EOF
 chmod +x tmpmultilib
 
-combinations=`initial=/ ./tmpmultilib ${options}`
+combinations=`initial=/ ${CONFIG_SHELL-/bin/sh} ./tmpmultilib ${options}`
 
 # If there exceptions, weed them out now
 if [ -n "${exceptions}" ]; then
@@ -210,7 +210,7 @@ cat >>tmpmultilib2 <<\EOF
   done
 EOF
   chmod +x tmpmultilib2
-  combinations=`./tmpmultilib2 ${combinations}`
+  combinations=`${CONFIG_SHELL-/bin/sh} ./tmpmultilib2 ${combinations}`
 fi
 
 # If the MULTILIB_REQUIRED list are provided,
@@ -236,7 +236,7 @@ cat >>tmpmultilib2 <<\EOF
 EOF
 
chmod +x tmpmultilib2
-   combinations=`./tmpmultilib2 ${combinations}`
+   combinations=`${CONFIG_SHELL-/bin/sh} ./tmpmultilib2 ${combinations}`
 
 fi
 
@@ -348,12 +348,12 @@ if [ "$#" = "0" ]; then
 else
   first=$1
   shift
-  dirout="${dirout}" optout="${optout}" ./tmpmultilib2 $@
+  dirout="${dirout}" optout="${optout}" ${CONFIG_SHELL-/bin/sh} ./tmpmultilib2 
$@
   l=`echo ${first} | sed -e 's/=.*$//' -e 's/?/=/g'`
   r=`echo ${first} | sed -e 's/^.*=//' -e 's/?/=/g'`
   if expr " ${optout} " : ".* ${l} .*" > /dev/null; then
 newopt=`echo " ${optout} " | sed -e "s/ ${l} / ${r} /" -e 's/^ //' -e 's/ 
$//'`
-dirout="${dirout}" optout="${newopt}" ./tmpmultilib2 $@
+dirout="${dirout}" optout="${newopt}" ${CONFIG_SHELL-/bin/sh} 
./tmpmultilib2 $@
   fi
 fi
 EOF
@@ -453,14 +453,14 @@ chmod +x tmpmultilib4
 # correct list of options and negations.
 for combo in ${combinations}; do
   # Use the directory names rather than the option names.
-  dirout=`./tmpmultilib3 "${combo}" "${todirnames}" "${toosdirnames}" 
"${enable_multilib}"`
+  dirout=`${CONFIG_SHELL-/bin/sh} ./tmpmultilib3 "${combo}" "${todirnames}" 
"${toosdirnames}" "${enable_multilib}"`
 
   # Look through the options.  We must output each option that is
   # present, and negate each option that is not present.
-  optout=`./tmpmultilib4 "${combo}" "${options}"`
+  optout=`${CONFIG_SHELL-/bin/sh} ./tmpmultilib4 "${combo}" "${options}"`
 
   # Output the line with all appropriate matches.
-  dirout="${dirout}" optout="${optout}" ./tmpmultilib2
+  dirout="${dirout}" optout="${optout}" ${CONFIG_SHELL-/bin/sh} ./tmpmultilib2
 done
 
 # Terminate the list of string.
@@ -491,11 +491,11 @@ for rrule in ${multilib_reuse}; do
   if expr "${combinations} " : ".*/${combo}/.*" > /dev/null; then
 if echo "/${copts}/" | grep -E "${options_re}" > /dev/null; then
   combo="/${combo}/"
-  dirout=`./tmpmultilib3 "${combo}" "${todirnames}" "${toosdirnames}" 
"${enable_multilib}"`
+  dirout=`${CONFIG_SHELL-/bin/sh} ./tmpmultilib3 "${combo}" 
"${todirnames}" "${toosdirnames}" "${enable_multilib}"`
   copts="/${copts}/"
-  optout=`./tmpmultilib4 "${copts}" "${options}"`
+  optout=`${CONFIG_SHELL-/bin/sh} ./tmpmultilib4 "${copts}" "${options}"`
   # Output the line with all appropriate matches.
-  dirout="${dirout}" optout="${optout}" ./tmpmultilib2
+  dirout="${dirout}" optout="${optout}" ${CONFIG_SHELL-/bin/sh} 
./tmpmultilib2
 else
   echo "The rule ${rrule} contains an option absent from 
MULTILIB_OPTIONS." >&2
   exit 1

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

harden-conditionals: detach values before compares

[Alexandre Oliva via Gcc-patches]

The optimization barriers inserted after compares enable GCC to derive
information about the values from e.g. the taken paths, or the absence
of exceptions.  Move them before the original compares, so that the
reversed compares test copies of the original operands, without
further optimizations.

Regstrapped on x86_64-linux-gnu, and also bootstrapped with both passes
enabled.  Further tested on multiple other targets with gcc-12.  Ok to
install?


for  gcc/ChangeLog

* gimple-harden-conditionals.cc (insert_edge_check_and_trap):
Move detach value calls...
(pass_harden_conditional_branches::execute): ... here.
(pass_harden_compares::execute): Detach values before
compares.

for  gcc/testsuite/ChangeLog

* c-c++-common/torture/harden-cond-comp.c: New.
---
 gcc/gimple-harden-conditionals.cc  |   25 
 .../c-c++-common/torture/harden-cond-comp.c|   24 +++
 2 files changed, 39 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/torture/harden-cond-comp.c

diff --git a/gcc/gimple-harden-conditionals.cc 
b/gcc/gimple-harden-conditionals.cc
index 78b8d5692d76f..2e5a42e9e71b1 100644
--- a/gcc/gimple-harden-conditionals.cc
+++ b/gcc/gimple-harden-conditionals.cc
@@ -276,8 +276,8 @@ insert_check_and_trap (location_t loc, gimple_stmt_iterator 
*gsip,
 }
 
 /* Split edge E, and insert_check_and_trap (see above) in the
-   newly-created block, using detached copies of LHS's and RHS's
-   values (see detach_value above) for the COP compare.  */
+   newly-created block, using already-detached copies of LHS's and
+   RHS's values (see detach_value above) for the COP compare.  */
 
 static inline void
 insert_edge_check_and_trap (location_t loc, edge e,
@@ -301,10 +301,6 @@ insert_edge_check_and_trap (location_t loc, edge e,
 
   gimple_stmt_iterator gsik = gsi_after_labels (chk);
 
-  bool same_p = (lhs == rhs);
-  lhs = detach_value (loc, , lhs);
-  rhs = same_p ? lhs : detach_value (loc, , rhs);
-
   insert_check_and_trap (loc, , flags, cop, lhs, rhs);
 }
 
@@ -366,6 +362,12 @@ pass_harden_conditional_branches::execute (function *fun)
/* ??? Can we do better?  */
continue;
 
+  /* Detach the values before the compares.  If we do so later,
+the compiler may use values inferred from the compares.  */
+  bool same_p = (lhs == rhs);
+  lhs = detach_value (loc, , lhs);
+  rhs = same_p ? lhs : detach_value (loc, , rhs);
+
   insert_edge_check_and_trap (loc, EDGE_SUCC (bb, 0), cop, lhs, rhs);
   insert_edge_check_and_trap (loc, EDGE_SUCC (bb, 1), cop, lhs, rhs);
 }
@@ -508,6 +510,13 @@ pass_harden_compares::execute (function *fun)
 
  tree rhs = copy_ssa_name (lhs);
 
+ /* Detach the values before the compares, so that the
+compiler infers nothing from them, not even from a
+throwing compare that didn't throw.  */
+ bool same_p = (op1 == op2);
+ op1 = detach_value (loc, , op1);
+ op2 = same_p ? op1 : detach_value (loc, , op2);
+
  gimple_stmt_iterator gsi_split = gsi;
  /* Don't separate the original assignment from debug stmts
 that might be associated with it, and arrange to split the
@@ -529,10 +538,6 @@ pass_harden_compares::execute (function *fun)
 gimple_bb (asgn)->index, nbb->index);
}
 
- bool same_p = (op1 == op2);
- op1 = detach_value (loc, _split, op1);
- op2 = same_p ? op1 : detach_value (loc, _split, op2);
-
  gassign *asgnck = gimple_build_assign (rhs, cop, op1, op2);
  gimple_set_location (asgnck, loc);
  gsi_insert_before (_split, asgnck, GSI_SAME_STMT);
diff --git a/gcc/testsuite/c-c++-common/torture/harden-cond-comp.c 
b/gcc/testsuite/c-c++-common/torture/harden-cond-comp.c
new file mode 100644
index 0..5aad890a1d3b6
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/torture/harden-cond-comp.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-fharden-conditional-branches -fharden-compares 
-fdump-tree-hardcbr -fdump-tree-hardcmp -ffat-lto-objects" } */
+
+int f(int i, int j) {
+  if (i == 0)
+return j != 0;
+  else
+return i * j != 0;
+}
+
+/* { dg-final { scan-tree-dump-times "Splitting edge" 2 "hardcbr" } } */
+/* { dg-final { scan-tree-dump-times "Adding reversed compare" 2 "hardcbr" } } 
*/
+/* { dg-final { scan-tree-dump-times "__builtin_trap" 2 "hardcbr" } } */
+
+/* { dg-final { scan-tree-dump-times "Splitting block" 2 "hardcmp" } } */
+/* { dg-final { scan-tree-dump-times "Adding reversed compare" 2 "hardcmp" } } 
*/
+/* { dg-final { scan-tree-dump-times "__builtin_trap" 4 "hardcmp" } } */
+
+/* Check that the optimization barrier is placed before the original compare.  
*/
+/* { dg-final { scan-tree-dump-times {__asm__[(]"" : "=g" _[0-9]* : "0" 
i_[0-9]*[(]D[)][)][;][\n][ ]*if [(]i_[0-9]*[(]D[)] == 0[)]} 1 "hardcbr" } 

Re: [PATCH v2 #1/2] enable adjustment of return_pc debug attrs

[Alexandre Oliva via Gcc-patches]

On Apr 14, 2023, Alexandre Oliva  wrote:

> On Mar 23, 2023, Alexandre Oliva  wrote:
>> This patch introduces infrastructure for targets to add an offset to
>> the label issued after the call_insn to set the call_return_pc
>> attribute.  This will be used on rs6000, that sometimes issues another
>> instruction after the call proper as part of a call insn.

> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614452.html
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614453.html

Ping?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

[Alexandre Oliva via Gcc-patches]

On Apr  7, 2023, "Kewen.Lin"  wrote:

> This new version causes unresolved record on my side, it's due to the
> compilation failed to produce executable.

Yeah, it does that, I didn't realize that was undesirable.

> So I think we need to make the file be compiled well, how about something 
> like:

That worked for me as well, so...

> ?  OK if it looks reasonable to you and the testing goes well.  Thanks!

... I'm putting this in, thanks:

[PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

When long double is 64-bit wide, as on vxworks, the rs6000 backend
defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
pr99708.c expected both to be always defined.  Adjust the test to
match the implementation.


Co-Authored-By: Kewen Lin 

for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr99708.c: Accept lack of
__SIZEOF_IBM128__ when long double is 64-bit wide.
---
 gcc/testsuite/gcc.target/powerpc/pr99708.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr99708.c 
b/gcc/testsuite/gcc.target/powerpc/pr99708.c
index 02b40ebc40d3d..c6aa0511b8925 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr99708.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr99708.c
@@ -14,9 +14,17 @@
 int main (void)
 {
   if (__SIZEOF_FLOAT128__ != sizeof (__float128)
-  || __SIZEOF_IBM128__ != sizeof (__ibm128))
+  /* FIXME: Once type __ibm128 gets supported with long-double-64,
+ we shouldn't need this conditional #ifdef and xfail.  */
+#ifdef __SIZEOF_IBM128__
+  || __SIZEOF_IBM128__ != sizeof (__ibm128)
+#else
+  || 1
+#endif
+ )
 abort ();
 
   return 0;
 }
 
+/* { dg-xfail-run-if "unsupported type __ibm128 with long-double-64" { 
longdouble64 } } */


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH v2 #1/2] enable adjustment of return_pc debug attrs

[Alexandre Oliva via Gcc-patches]

On Mar 23, 2023, Alexandre Oliva  wrote:

> This patch introduces infrastructure for targets to add an offset to
> the label issued after the call_insn to set the call_return_pc
> attribute.  This will be used on rs6000, that sometimes issues another
> instruction after the call proper as part of a call insn.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614452.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614453.html

This is a new feature, but it's needed to avoid regressions with the
recently-released GDB on ppc64.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [testsuite] [ppc] expect vectorization in gen-vect-11c.c

[Alexandre Oliva via Gcc-patches]

On Apr  6, 2023, "Kewen.Lin"  wrote:

> on 2023/4/6 13:20, Alexandre Oliva wrote:
>> I confirm I observe the problem with gcc-12 targeting ppc64-vx7r2,
>> containing the backported patch, and that the loop is vectorized,
>> failing the test.

I take that back.  My notes indicate I looked into this failure on March
15th.  The patch you referenced was dated Feb 10, so I assumed it was
already in when I looked into it: my confirmation amounted to checking
what I had observed according to my notes, and when.

But now that you asked me to investigate it again, I used a far more
recent tree, and I failed to duplicate it.  Digging further, I found out
the patch, despite its commit date, was only merged into gcc-12 on March
16th.  What I was missing to get the intended effects of the fix was
just a fresher tree athat actually contained the fix.

I suppose this means we don't need the testsuite tweak, after all.
Patch withdrawn.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [testsuite] [ppc] skip ppc-fortran if fortran is disabled

[Alexandre Oliva via Gcc-patches]

Hello, Kewen,

On Apr  6, 2023, "Kewen.Lin"  wrote:

> on 2023/4/6 14:19, Alexandre Oliva wrote:

>> Skip ppc-fortran.exp if a trivial fortran program cannot be compiled.

> IIUC, without this patch and under the configuration disabling fortran,
> all the cases in this sub-testsuite would fail?  Thanks for fixing!

Yup

> super nit: this check only needs proc check_no_compiler_messages,
> can it be moved a bit upward just after line "load_lib gfortran-dg.exp"
> then it can skip more unnecessary codes?

I wasn't sure, so I'd put it after supporting code.  Turns out it can.
Here's what I've just finished retesting, and am thus checking in.
Thanks,

> OK with this nit fixed (if you agree).  Thanks!


[testsuite] [ppc] skip ppc-fortran if fortran is disabled

Skip ppc-fortran.exp if a trivial fortran program cannot be compiled.


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp: Test for
fortran compiler, skip if missing.
---
 .../gcc.target/powerpc/ppc-fortran/ppc-fortran.exp |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp 
b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
index f7e99ac848753..f7b7c05487cda 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
+++ b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
@@ -21,6 +21,16 @@ if { ![istarget powerpc*-*-*] && ![istarget rs6000-*-*] } 
then {
   return
 }
 
+# Make sure there is a fortran compiler to test.
+if { ![check_no_compiler_messages fortran_available assembly {
+! Fortran
+program P
+  stop
+end program P
+} ""] } {
+return
+}
+
 # Load support procs.
 load_lib gfortran-dg.exp
 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

[Alexandre Oliva via Gcc-patches]

On Apr  6, 2023, "Kewen.Lin"  wrote:

> The reason why personally I preferred to fix it with xfail is that:

Got it.  I'm convinced, and I agree.

I tried an xfail in the initial dg-do, but that is no good for a compile
error, so I went for a dg-bogus xfail.  I hope that will still have the
intended effect when __ibm128 is defined when it currently isn't.

There is a dg-skip-if in this test on the trunk, covering some targets,
that IIRC are longdouble64, so maybe that's related and I could have
dropped them, but I wasn't sure, so I left them alone.

Regstrapped on ppc64-linux-gnu (pass), also tested on ppc64-vx7r2/gcc-12
(xfail).  Ok to install?


[PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

When long double is 64-bit wide, as on vxworks, the rs6000 backend
defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
pr99708.c expected both to be always defined.  Adjust the test to
match the implementation.


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr99708.c: Accept lack of
__SIZEOF_IBM128__ when long double is 64-bit wide.
---
 gcc/testsuite/gcc.target/powerpc/pr99708.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr99708.c 
b/gcc/testsuite/gcc.target/powerpc/pr99708.c
index 02b40ebc40d3d..66a5f88479330 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr99708.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr99708.c
@@ -14,7 +14,7 @@
 int main (void)
 {
   if (__SIZEOF_FLOAT128__ != sizeof (__float128)
-  || __SIZEOF_IBM128__ != sizeof (__ibm128))
+  || __SIZEOF_IBM128__ != sizeof (__ibm128)) /* { dg-bogus "undeclared" "" 
{ xfail longdouble64 } } */
 abort ();
 
   return 0;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

[Alexandre Oliva via Gcc-patches]

On Apr  6, 2023, Thomas Schwinge  wrote:

> Eh, given your "Ooh, nice, I didn't know [...]" comment in
> :

Oh my, you're right, I apologize, I misremembered.  When I wrote "before
I saw your patch" yesterday, I meant the formal, already-tested patch
submission, that I recall seeing while I tested the patchlet I'd posted.
I forgot you had included that patch also in the initial report, but I
see it there too.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614884.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614880.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614857.html

I learned that tcl trick from you indeed, and that much I remember
clearly: I've long sought but failed to find a way to do that.

Alas, for some reason, I had a misrecollection that you had merely
recommended using that trick, instead of including an actual patch, in
the report I claimed to have based the patch on.  I suppose I may have
drawn that wrong conclusion from my having set out to write a patch
myself, instead of recommending the approval of yours.  That, in turn,
was presumably because there was an additional issue that needed fixing,
and that you had asked me to look into.  Anyhow, it's probably a safe
bet that I based our patch on yours indeed, but I wouldn't be able to
confirm or deny it either way: those details have unfortunately faded
away from my memory.

Anyway, it was based on the misrecollection that I stated "before even
seeing your patch", and I acknowledge that I was wrong, and probably
also overthinking the whole issue ;-)

Please accept my embarrassed apologies.  I think I had better memory
when I was younger, but I'm not really sure, I can't recall ;-D

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] [ppc] skip ppc-fortran if fortran is disabled

[Alexandre Oliva via Gcc-patches]

Skip ppc-fortran.exp if a trivial fortran program cannot be compiled.

Regstrapped on x86_64-linux-gnu and ppc64-linux-gnu.  Also tested on
ppc64-vx7r2 with gcc-12, with the Fortran language disabled.  Ok to
install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp: Test for
fortran compiler, skip if missing.
---
 .../gcc.target/powerpc/ppc-fortran/ppc-fortran.exp |9 +
 1 file changed, 9 insertions(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp 
b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
index f7e99ac848753..d05c27ab589a7 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
+++ b/gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp
@@ -33,6 +33,15 @@ if ![info exists DEFAULT_FFLAGS] then {
 # Initialize `dg'.
 dg-init
 
+if { ![check_no_compiler_messages fortran_available assembly {
+! Fortran
+program P
+  stop
+end program P
+} ""] } {
+return
+}
+
 global gfortran_test_path
 global gfortran_aux_module_flags
 set gfortran_test_path $srcdir/$subdir

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [testsuite] [ppc] expect vectorization in gen-vect-11c.c

[Alexandre Oliva via Gcc-patches]

Hello, Kewen,

On Mar 27, 2023, "Kewen.Lin"  wrote:

> on 2023/3/25 16:35, Alexandre Oliva wrote:

>> The first loop in main gets stores "vectorized" on powerpc into
>> full-word stores, even without any vector instruction support, so the
>> test's expectation of no loop vectorization is not met.

> I think this test issue has been gone since r13-5771-gdc87e1391c55c6.

That patch has been backported to gcc-12 as r12-9258-g21e7145aaf582c.

> Could you have a double check?

I confirm I observe the problem with gcc-12 targeting ppc64-vx7r2,
containing the backported patch, and that the loop is vectorized,
failing the test.


It's unfortunately not viable for me to test GCC trunk with vxworks, so
my testing with it is limited to earlier GCC versions, that we (AdaCore)
have already ported or are in the process of porting.  I make up for
that by testing trunk with other target variants, to the best of my
abilities, to avoid regressions, but sometimes I just can't tell whether
my baseline for regression testing doesn't contain a failure because
there's another fix, or because it just doesn't fail on that target
variant.


In this case, the comments in the patch you mentioned don't seem to
match the situation at hand: the SImode stores vectorized into V2SImode
(DImode) seem profitable and are *not* split by vector lowering.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

[Alexandre Oliva via Gcc-patches]

Hello, Kewen,

Thanks for the feedback.

On Mar 27, 2023, "Kewen.Lin"  wrote:

> on 2023/3/25 16:37, Alexandre Oliva via Gcc-patches wrote:
>> 
>> When long double is 64-bit wide, as on vxworks, the rs6000 backend
>> defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
>> pr99708.c expected both to be always defined.  Adjust the test to
>> match the implementation.

> There is one patch from Mike to define type __ibm128 even without
> IEEE 128-bit floating point support, it's at the link:

> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599984.html

> I would expect this issue would be gone if the adjustment on the
> support of type __ibm128 gets landed in future.

Yeah, the issue would then be gone, but the patch is compatible with
that proposed change: if __ibm128 and the corresponding SIZEOF macro are
defined, the proposed change is a no-op.

> So maybe we can just xfail this for longdouble64?  What do you
> think?

I wouldn't object to that, and I could even write and test the alternate
patch for that, but I fail to understand why that would be more
desirable.  Would you be so kind as to enlighten me?

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

[Alexandre Oliva via Gcc-patches]

On Apr  5, 2023, Thomas Schwinge  wrote:

> Given the two "OK"s that you got end of last week, are you going to push
> that anytime soon, please?

Apologies for the delay.

> With...

> Co-authored-by: Thomas Schwinge 

> ... added, I suppose.

I wrote the patch based on your report, before even seeing your patch,
though I only posted mine later, so I tried to give you credit for the
report in the commit message, but if you feel that the note is
appropriate, sure :-)  Thanks again!

Here's what I'm checking in.


testsuite: fix proc unsupported overriding in modules.exp [PR108899]

The overrider of proc unsupported in modules.exp had two problems
reported by Thomas Schwinge, even after Jakub Jelínek's fix:

- it remained in effect while running other dejagnu testsets

- it didn't quote correctly the argument list passed to it, which
  caused test names to be surrounded by curly braces, as in:

UNSUPPORTED: {...}

This patch fixes both issues, obsoleting and reverting Jakub's change,
by dropping the overrider and renaming the saved proc back, and by
using uplevel's argument list splicing.


Co-authored-by: Thomas Schwinge 

for  gcc/testsuite/ChangeLog

PR testsuite/108899
* g++.dg/modules/modules.exp (unsupported): Drop renaming.
Fix quoting.
---
 gcc/testsuite/g++.dg/modules/modules.exp |   20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/g++.dg/modules/modules.exp 
b/gcc/testsuite/g++.dg/modules/modules.exp
index 80aa392bc7f3b..dc302d3d0af48 100644
--- a/gcc/testsuite/g++.dg/modules/modules.exp
+++ b/gcc/testsuite/g++.dg/modules/modules.exp
@@ -319,15 +319,11 @@ cleanup_module_files [find $DEFAULT_REPO *.gcm]
 # so that, after an unsupported result in dg-test, we can skip rather
 # than fail subsequent related tests.
 set module_do {"compile" "P"}
-if { [info procs unsupported] != [list] \
-  && [info procs saved-unsupported] == [list] } {
-rename unsupported saved-unsupported
-
-proc unsupported { args } {
-   global module_do
-   lset module_do 1 "N"
-   return [saved-unsupported $args]
-}
+rename unsupported modules-saved-unsupported
+proc unsupported { args } {
+global module_do
+lset module_do 1 "N"
+return [uplevel 1 modules-saved-unsupported $args]
 }
 
 # not grouped tests, sadly tcl doesn't have negated glob
@@ -412,4 +408,10 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
 }
 }
 
+# Restore the original unsupported proc, lest it will affect
+# subsequent test runs, or even fail renaming if we run modules.exp
+# for multiple targets/multilibs/options.
+rename unsupported {}
+rename modules-saved-unsupported unsupported
+
 dg-finish



-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Introduce -nolibstdc++ option

[Alexandre Oliva via Gcc-patches]

On Mar 30, 2023, Gerald Pfeifer  wrote:

> On Thu, 30 Mar 2023, Alexandre Oliva wrote:
>> How about this, does this seem useful?

> I like it - helpful and easy to understand. :-)

'k, I'm putting it in, thanks


On Mar 30, 2023, Arsen Arsenović  wrote:

> IMO, yes - in fact, the libstdc++ manual even has a use-case for this

Yeah, and it also had the means to accomplish that already.  -nostdlib++
was for the testsuite, that always uses g++ for linking C++ tests.

I suppose libstdc++ now has an alternative it might consider switching
to, namely using g++ -nostdlib++ rather than gcc to link itself, but
should it?  I don't see the upside.  Its build process is not broken,
it's not even inconvenient, so what's the expected benefit that the
change would bring about?  As for downsides, I perceive risks of build
scripts (e.g. libtool)'s not yet having support for -nostdlib++, and
thus trying to use the flag could break rather than improve the state of
affairs.  It feels like inviting trouble to me.

> If you think the flag you added fits here, would you mind also including
> this file in your patch?

The patch was for the online release documentation, it's not even the
same repository as libstdc++, so there's no way to add it to the same
patch.

Given that, and since I'm not so sure I understand what change you're
suggesting to libstdc++'s manual or build procedures, how about you
give it a shot yourself?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

[Alexandre Oliva via Gcc-patches]

On Mar 30, 2023, Alexandre Oliva  wrote:

> If we're dropping the renaming, I suppose we could also revert Jakub's
> change.  I suppose this patch will take care of it, pending testing...

Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with
gcc-12), where I used to get fails after an unsupported modules.exp
test, but there are no curly braces in the log files after the patch.
Ok to install?


[PR108899] testsuite: fix proc unsupported overriding in modules.exp

The overrider of proc unsupported in modules.exp had two problems
reported by Thomas Schwinge, even after Jakub Jelínek's fix:

- it remained in effect while running other dejagnu testsets

- it didn't quote correctly the argument list passed to it, which
  caused test names to be surrounded by curly braces, as in:

UNSUPPORTED: {...}

This patch fixes both issues, obsoleting and reverting Jakub's change,
by dropping the overrider and renaming the saved proc back, and by
using uplevel's argument list splicing.


for  gcc/testsuite/ChangeLog

PR testsuite/108899
* g++.dg/modules/modules.exp (unsupported): Drop renaming.
Fix quoting.
---
 gcc/testsuite/g++.dg/modules/modules.exp |   20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/g++.dg/modules/modules.exp 
b/gcc/testsuite/g++.dg/modules/modules.exp
index 80aa392bc7f3b..dc302d3d0af48 100644
--- a/gcc/testsuite/g++.dg/modules/modules.exp
+++ b/gcc/testsuite/g++.dg/modules/modules.exp
@@ -319,15 +319,11 @@ cleanup_module_files [find $DEFAULT_REPO *.gcm]
 # so that, after an unsupported result in dg-test, we can skip rather
 # than fail subsequent related tests.
 set module_do {"compile" "P"}
-if { [info procs unsupported] != [list] \
-  && [info procs saved-unsupported] == [list] } {
-rename unsupported saved-unsupported
-
-proc unsupported { args } {
-   global module_do
-   lset module_do 1 "N"
-   return [saved-unsupported $args]
-}
+rename unsupported modules-saved-unsupported
+proc unsupported { args } {
+global module_do
+lset module_do 1 "N"
+return [uplevel 1 modules-saved-unsupported $args]
 }
 
 # not grouped tests, sadly tcl doesn't have negated glob
@@ -412,4 +408,10 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
 }
 }
 
+# Restore the original unsupported proc, lest it will affect
+# subsequent test runs, or even fail renaming if we run modules.exp
+# for multiple targets/multilibs/options.
+rename unsupported {}
+rename modules-saved-unsupported unsupported
+
 dg-finish


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Introduce -nolibstdc++ option

[Alexandre Oliva via Gcc-patches]

Hello, Gerald,

On Feb 11, 2023, Gerald Pfeifer  wrote:

> On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
>> Introduce -nostdlib++ option
>> 
>> Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C,
>> is error prone, because there's no way to tell g++ to drop libstdc++
>> without also dropping libc and any other libraries that the target
>> implicitly links in.

> % grep -r nostdlib $WWWDOCS
> %

> Should this be documented in gcc-13/changes.html? Would you mind proposing 
> a snippet (or going ahead and pushing it)?

I can't make my mind up about this.

At first, the goal of adding the option was just to aid this specific
test.  But then, it transpired that other compilers offered a similar
option, with the spelling that we ended up using, so perhaps it would
make sense to document it, after all.

How about this, does this seem useful?

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index ff70d2eefecec..c1bbbfa28e18e 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -333,6 +333,9 @@ a work-in-progress.
   The https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wpessimizing-move;>-Wpessimizing-move
 and https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wredundant-move;>-Wredundant-move
 warnings have been extended to warn in more contexts.
+  The https://gcc.gnu.org/onlinedocs/gcc/Link_Options.html#index-nostdlib_002b_002b;>-nostdlib++
+option has been added, to enable linking with g++
+without implicitly linking in the C++ standard library.
 
 
 Runtime Library (libstdc++)


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]

[Alexandre Oliva via Gcc-patches]

On Mar 29, 2023, Thomas Schwinge  wrote:

> I assume that the second UNSUPPORTED:

> -UNSUPPORTED: g++.dg/modules/explicit-bool-1_b.C -std=c++17

> ... disappears is the intention of this patch?

Yup

> But surely the curly braces in:

> -UNSUPPORTED: g++.dg/modules/explicit-bool-1_a.H -std=c++17

> +UNSUPPORTED: {g++.dg/modules/explicit-bool-1_a.H -std=c++17}

> ... are not intentional?  (Alexandre?)

Unintended indeed, will look, thanks for letting me know


> But worse, the latter also "bleeds into" all other testing

Eeek

Yeah, that's a much bigger problem indeed.

> ..., this isn't sufficient.  Instead, we should undo the 'rename' at the
> end of 'g++.dg/modules/modules.exp'.  OK to push the attached
> "'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]"
> after proper testing?

Ooh, nice, I didn't know how to drop the renaming after we were done
with it, and hoped the end of the .exp would have accomplished that by
ending a scope.  Jakub had already pointed out this wasn't the case, but
I didn't realize, when he did, that this would carry over onto other
modules.


If we're dropping the renaming, I suppose we could also revert Jakub's
change.  I suppose this patch will take care of it, pending testing...


diff --git a/gcc/testsuite/g++.dg/modules/modules.exp 
b/gcc/testsuite/g++.dg/modules/modules.exp
index 80aa392bc7f3b..6fd5050cef79b 100644
--- a/gcc/testsuite/g++.dg/modules/modules.exp
+++ b/gcc/testsuite/g++.dg/modules/modules.exp
@@ -319,15 +319,11 @@ cleanup_module_files [find $DEFAULT_REPO *.gcm]
 # so that, after an unsupported result in dg-test, we can skip rather
 # than fail subsequent related tests.
 set module_do {"compile" "P"}
-if { [info procs unsupported] != [list] \
-  && [info procs saved-unsupported] == [list] } {
-rename unsupported saved-unsupported
-
-proc unsupported { args } {
-   global module_do
-   lset module_do 1 "N"
-   return [saved-unsupported $args]
-}
+rename unsupported modules-saved-unsupported
+proc unsupported { args } {
+global module_do
+lset module_do 1 "N"
+return [eval modules-saved-unsupported $args]
 }
 
 # not grouped tests, sadly tcl doesn't have negated glob
@@ -412,4 +408,10 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
 }
 }
 
+# Restore the original unsupported proc, lest it will affect
+# subsequent test runs, or even fail renaming if we run modules.exp
+# for multiple targets/multilibs/options.
+rename unsupported {}
+rename modules-saved-unsupported unsupported
+
 dg-finish


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] enable -maltivec like vect_int for signbit-2.c

[Alexandre Oliva via Gcc-patches]

Explicitly enable altivec if it's supported.  vect_int tests for
powerpc_altivec_ok, but without the explicit option, if altivec is not
enabled by default, we end up expecting vectorization that doesn't
occur.

Regstrapped on ppc64-linux-gnu.  Also tested with ppc64-vxworks7r2
(gcc-12).  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/signbit-2.c: Add -maltivec if supported.
---
 gcc/testsuite/gcc.dg/signbit-2.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index 1624225820703..d7b406effc62d 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -4,6 +4,7 @@
 /* This test does not work when the truth type does not match vector type.  */
 /* { dg-additional-options "-mno-avx512f" { target { i?86-*-* x86_64-*-* } } } 
*/
 /* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
+/* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
 /* { dg-skip-if "no fallback for MVE" { arm_mve } } */
 
 #include 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [rs6000] Correct match pattern in pr56605.c

[Alexandre Oliva via Gcc-patches]

Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html

From: Haochen Gui 

This patch corrects the match pattern in pr56605.c. The former pattern
is wrong and test case fails with GCC11. It should match following
insn on each subtarget after mode promotion is disabled. The patch
need to be backported to GCC11.

//gimple
_17 = (unsigned int) _20;
 prolog_loop_niters.4_23 = _17 & 3;

//rtl
(insn 19 18 20 2 (parallel [
(set (reg:CC 208)
(compare:CC (and:SI (subreg:SI (reg:DI 207) 0)
(const_int 3 [0x3]))
(const_int 0 [0])))
(set (reg:SI 129 [ prolog_loop_niters.5 ])
(and:SI (subreg:SI (reg:DI 207) 0)
(const_int 3 [0x3])))
]) 197 {*andsi3_imm_mask_dot2}

Rebased.  Regstrapped on ppc64-linux-gnu.  Also tested with
ppc64-vxworks7r2 (gcc-12), where it's also needed.  Ok to install?


for  gcc/testsuite/ChangeLog

PR target/102146
* gcc.target/powerpc/pr56605.c: Correct match pattern in
combine pass.
---
 gcc/testsuite/gcc.target/powerpc/pr56605.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c 
b/gcc/testsuite/gcc.target/powerpc/pr56605.c
index 7695f87db6f66..651a88e3cc7f9 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
@@ -11,5 +11,4 @@ void foo (short* __restrict sb, int* __restrict ia)
 ia[i] = (int) sb[i];
 }
 
-/* { dg-final { scan-rtl-dump-times {\(compare:CC 
\((?:and|zero_extend):(?:[SD]I) \((?:sub)?reg:[SD]I} 1 "combine" } } */
-
+/* { dg-final { scan-rtl-dump-times {\(compare:CC \(and:SI \(subreg:SI 
\(reg:DI} 1 "combine" } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [PR99708] [rs6000] don't expect __ibm128 with 64-bit long double

[Alexandre Oliva via Gcc-patches]

When long double is 64-bit wide, as on vxworks, the rs6000 backend
defines neither the __ibm128 type nor the __SIZEOF_IBM128__ macro, but
pr99708.c expected both to be always defined.  Adjust the test to
match the implementation.

Regstrapped on ppc64-linux-gnu.  Also tested with ppc64-vxworks7r2
(gcc-12).  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr99708.c: Accept lack of
__SIZEOF_IBM128__ when long double is 64-bit wide.
---
 gcc/testsuite/gcc.target/powerpc/pr99708.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr99708.c 
b/gcc/testsuite/gcc.target/powerpc/pr99708.c
index 02b40ebc40d3d..fca6296d9c81f 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr99708.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr99708.c
@@ -14,7 +14,13 @@
 int main (void)
 {
   if (__SIZEOF_FLOAT128__ != sizeof (__float128)
-  || __SIZEOF_IBM128__ != sizeof (__ibm128))
+#ifdef __SIZEOF_IBM128__ /* Not defined, and no __ibm128 type on targets whose
+   long double is 64-bit.  */
+  || __SIZEOF_IBM128__ != sizeof (__ibm128)
+#else
+  || __SIZEOF_LONG_DOUBLE__ * __CHAR_BIT__ != 64
+#endif
+  )
 abort ();
 
   return 0;

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] [ppc] expect vectorization in gen-vect-11c.c

[Alexandre Oliva via Gcc-patches]

The first loop in main gets stores "vectorized" on powerpc into
full-word stores, even without any vector instruction support, so the
test's expectation of no loop vectorization is not met.

Regstrapped on ppc64-linux-gnu.  Also tested with ppc64-vxworks7r2
(gcc-12).  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/tree-ssa/gen-vect-11c.c: xfail the test for no
vectorization on powerpc*-*-*.
---
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c 
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c
index 22ff44cf66da9..116f6af233887 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c
@@ -39,4 +39,4 @@ int main ()
 }
 
 
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { xfail 
amdgcn*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { xfail 
amdgcn*-*-* powerpc*-*-* } } } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [testsuite] test for weak_undefined support and add options

[Alexandre Oliva via Gcc-patches]

On Mar 18, 2023, Mike Stump  wrote:

> On Mar 15, 2023, at 11:40 PM, Alexandre Oliva  wrote:
>> 
>> On Mar 15, 2023, Alexandre Oliva  wrote:
>> 
>>> Regstrapped on ppc64-linux-gnu.  Also tested (with gcc-12) on multiple
>>> *-vxworks7r2 targets (arm, aarch64, ppc64, x86, x86_64).  Ok to install?
>> 
>> Further testing revealed a problem in my attempted use of lappend in
>> aapcs64.exp, in the previous version of the patch.  Fixed in this one,
>> retested on aarch64-vxworks7r2.  Ok to install?

> Ok.

Thanks.  Marc Poulhies pointed out I'd failed to document the new dg
bits (thanks!).  Fixed below.  I'm going to check it if there are no
objections in the next 24 hours.


[testsuite] test for weak_undefined support and add options

A number of tests that depend on weak undefined symbols fail to
require that support, and arrange to skip some targets and add special
options to others on a test-by-test basis.  Fix this by stating the
requirement explicitly, and adding a proc to return any required
options.

Others rely on weak undefined symbols only to test for the
availability of posix_memalign.  Drop that in favor of dg effective
target support for posix_memalign.


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (add_options_for_weak_undefined):
New.
(check_effective_target_weak_undefined): Use it.
(check_effective_target_posix_memalign): New.
* doc/sourcebuild.texi: Document them.
* gcc.dg/torture/pr53922.c: Drop skips and custom options in
favor of effective target requirement and added options for
weak_undefined symbols.
* gcc.dg/torture/pr90020.c: Likewise.
* gcc.dg/addr_equal-1.c: Likewise.
* gcc.target/aarch64/aapcs64/aapcs64.exp: Likewise, for
abitest.S-using tests.
* gcc.dg/torture/pr60092.c: Likewise, but in favor of
posix_memalign tests.
* gcc.dg/vect/vect-tail-nomask-1.c: Likewise.
---
 gcc/doc/sourcebuild.texi   |9 ++
 gcc/testsuite/gcc.dg/addr_equal-1.c|5 +---
 gcc/testsuite/gcc.dg/torture/pr53922.c |   10 +--
 gcc/testsuite/gcc.dg/torture/pr60092.c |   12 +
 gcc/testsuite/gcc.dg/torture/pr90020.c |7 +
 gcc/testsuite/gcc.dg/vect/vect-tail-nomask-1.c |   11 +---
 .../gcc.target/aarch64/aapcs64/aapcs64.exp |   17 +++-
 gcc/testsuite/lib/target-supports.exp  |   28 ++--
 8 files changed, 54 insertions(+), 45 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 80bef7f0a0e22..c430bceb33ae8 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2697,6 +2697,9 @@ Target supports Newlib.
 GCC was configured with @code{--enable-newlib-nano-formatted-io}, which reduces
 the code size of Newlib formatted I/O functions.
 
+@item posix_memalign
+Target supports @code{posix_memalign}.
+
 @item pow10
 Target provides @code{pow10} function.
 
@@ -2759,6 +2762,9 @@ Target is a VxWorks RTP.
 
 @item wchar
 Target supports wide characters.
+
+@item weak_undefined
+Target supports weak undefined symbols
 @end table
 
 @subsubsection Other attributes
@@ -3130,6 +3136,9 @@ instructions, if any.
 
 @item tls
 Add the target-specific flags needed to use thread-local storage.
+
+@item weak_undefined
+Add the flags needed to enable support for weak undefined symbols.
 @end table
 
 @node Require Support
diff --git a/gcc/testsuite/gcc.dg/addr_equal-1.c 
b/gcc/testsuite/gcc.dg/addr_equal-1.c
index 35fa0102e3063..db65dea4a8d2a 100644
--- a/gcc/testsuite/gcc.dg/addr_equal-1.c
+++ b/gcc/testsuite/gcc.dg/addr_equal-1.c
@@ -1,9 +1,8 @@
-/* { dg-do run { target { nonpic || pie_enabled } } } */
-/* { dg-require-weak "" } */
+/* { dg-do run { target { { nonpic || pie_enabled } && weak_undefined } } } */
 /* { dg-require-alias "" } */
 /* { dg-options "-O2 -fdelete-null-pointer-checks" } */
-/* { dg-skip-if "" { powerpc-ibm-aix* } } */
 /* { dg-skip-if "function pointers can be NULL" { keeps_null_pointer_checks } 
} */
+/* { dg-add-options weak_undefined } */
 void abort (void);
 extern int undef_var0, undef_var1;
 extern __attribute__ ((weak)) int weak_undef_var0;
diff --git a/gcc/testsuite/gcc.dg/torture/pr53922.c 
b/gcc/testsuite/gcc.dg/torture/pr53922.c
index b3f2c1a58f830..07359d6764964 100644
--- a/gcc/testsuite/gcc.dg/torture/pr53922.c
+++ b/gcc/testsuite/gcc.dg/torture/pr53922.c
@@ -1,11 +1,5 @@
-/* { dg-do run } */
-/* { dg-require-weak "" } */
-/* { dg-skip-if "No undefined" { *-*-mingw* } } */
-/* { dg-skip-if "No undefined weak" { *-*-aix* } } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* && { ! lp64 } } } */
-/* { dg-skip-if "No undefined weak" { nvptx-*-* } } */
-/* { dg-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* } } */
-/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } } 
*/
+/* { dg-do run { target { weak_undefined } } } */
+/* { 

[PATCH v2 #2/2] [rs6000] adjust return_pc debug attrs

[Alexandre Oliva via Gcc-patches]

Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
out of a single call insn, but the call (bl) or jump (b) is not always
the last opcode in the sequence.

This does not seem to be a problem for exception handling tables, but
the return_pc attribute in the call graph output in dwarf2+ debug
information, that takes the address of a label output right after the
call, does not match the value of the link register even for non-tail
calls.  E.g., with ABI_AIX or ABI_ELFv2, such code as:

  foo ();

outputs:

  bl foo
  nop
 LVL#:
[...]
  .8byte .LVL#  # DW_AT_call_return_pc

but debug info consumers may rely on the return_pc address, and draw
incorrect conclusions from its off-by-4 value.

This patch uses the infrastructure for targets to add an offset to the
label issued after the call_insn to set the call_return_pc attribute,
on rs6000, to account for opcodes issued after actual call opcode as
part of call insns output patterns.

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


for  gcc/ChangeLog

* config/rs6000/rs6000.cc (TARGET_CALL_OFFSET_RETURN_LABEL):
Override.
(rs6000_call_offset_return_label): New.
---
 gcc/config/rs6000/rs6000.cc |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 8e0b0d022db2f..e55117159b270 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -1760,6 +1760,9 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 
 #undef TARGET_UPDATE_IPA_FN_TARGET_INFO
 #define TARGET_UPDATE_IPA_FN_TARGET_INFO rs6000_update_ipa_fn_target_info
+
+#undef TARGET_CALL_OFFSET_RETURN_LABEL
+#define TARGET_CALL_OFFSET_RETURN_LABEL rs6000_call_offset_return_label
 
 
 /* Processor table.  */
@@ -14593,6 +14596,22 @@ rs6000_assemble_integer (rtx x, unsigned int size, int 
aligned_p)
   return default_assemble_integer (x, size, aligned_p);
 }
 
+/* Return the offset to be added to the label output after CALL_INSN
+   to compute the address to be placed in DW_AT_call_return_pc.  */
+
+static int
+rs6000_call_offset_return_label (rtx_insn *call_insn)
+{
+  /* All rs6000 CALL_INSN output patterns start with a b or bl, always
+ a 4-byte instruction, but some output patterns issue other
+ opcodes afterwards.  The return label is issued after the entire
+ call insn, including any such post-call opcodes.  Instead of
+ figuring out which cases need adjustments, we compute the offset
+ back to the address of the call opcode proper, then add the
+ constant 4 bytes, to get the address after that opcode.  */
+  return 4 - get_attr_length (call_insn);
+}
+
 /* Return a template string for assembly to emit when making an
external call.  FUNOP is the call mem argument operand number.  */
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [rs6000] adjust return_pc debug attrs

[Alexandre Oliva via Gcc-patches]

On Mar 13, 2023, Segher Boessenkool  wrote:

> Hi!
> This is stage 1 stuff (or does it fix some regression or such?)

> On Fri, Mar 03, 2023 at 03:00:02PM -0300, Alexandre Oliva wrote:
>> Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
>> out of a single call insn, but the call (bl) or jump (b) is not always
>> the last opcode in the sequence.

> Yes.  On most architectures you can get multiple machine instructions of
> course (for long calls for example), but on rs6000 (with some ABIs, in
> some circumstances) we generate a nop insn after calls, so that the
> linker has a spot to insert fixup code after calls (typically to restore
> the r2 contents, but it could be anything).

Thanks.  I wasn't entirely sure that the linker would never ever relax
the call sequence, moving the bl to the second instruction in the pair,
or that no 64-bit call variant existed or would come into existence.


> Subtracting 4 from what we currently return is very fragile.

Agreed.

> The actual return address is *always* the address of the branch insn
> plus 4, can't you use that?

Yup, given this piece of knowledge I didn't have, I agree that's a far
saner approach.  I'll post a new version of the patch, now broken up
into rs6000-specific and machine-independent, momentarily.

> (Does the GCC code handle delay slots here, btw?

It does, in that the label is output after the insn sequence.

>> This patch introduces infrastructure for targets to add an offset to
>> the label issued after the call_insn to set the call_return_pc
>> attribute, and uses that on rs6000 to account for nop and l opcodes
>> issued after actual call opcode as part of call insns output patterns.

> What is an "l opcode"?

I have a vague recollection of seeing call sequences ended by loads.
Ah, yes, rs6000_indirect_call_template_1 outputs ld or lwz, depending on
TARGET_64BIT, in both speculate and non-speculate cases after the branch
in ABI_AIX and ABI_ELFv2 calls.  I understand the l in ld and lwz stands
for 'load', and so I meant 'load' updates, but I guess in the context of
calls the 'l' can indeed be misleading.  Anyway, that complexity is gone
thanks to your suggestion.

>> +/* Return the offset to be added to the label output after CALL_INSN
>> +   to compute the address to be placed in DW_AT_call_return_pc.  Some
>> +   call insns output nop or l after bl, so the return address would be
>> +   wrong without this offset.  */
>> +
>> +static int
>> +rs6000_call_offset_return_label (rtx_insn *call_insn)
>> +{
>> +  /* We don't expect SEQUENCEs in this port.  */
>> +  gcc_checking_assert (GET_CODE (call_insn) == CALL_INSN);

> That is not doing what the comment says.

It is.  The documented interface, in the .def file, states that it must
be either a CALL_INSN or a SEQUENCE.

> But, is the assert useful at all anyway, won't the callers have
> checked for this already?

No, the callers would let a SEQUENCE through, if there was one.  But
rs6000 won't ever see one, because there are no delay slots.

My rationale to put it in was to (i) confirm that the case of SEQUENCEs
was considered and needs not be handled in this port, and (ii) should
someone take inspiration from this implementation of the hook for a port
that supported delay slots, it would have to be handled.


>> +  enum attr_call_needs_return_offset cnro
>> += get_attr_call_needs_return_offset (call_insn);
>> +
>> +  if (cnro == CALL_NEEDS_RETURN_OFFSET_NONE)
>> +return 0;

>   if (get_attr_call_needs_return_offset (call_insn)
>   == CALL_NEEDS_RETURN_OFFSET_NONE)
> return 0;

> Shorter, simpler, doesn't need a variable for which you have no good
> name :-)

I happen to not share your subjective preference, but I don't mind
following that style in code you maintain.


>> +  if (rs6000_pcrel_p ())
>> +return 0;

> Why this?  Please look at what actual code is generated, don't assume
> you don't need anything here if we generate pcrel code?

It was not an assumption, I took the conditions from the code, both from
output functions in rs6000.cc and from call patterns in rs6000.md.

Both rs6000_call_template_1 and rs6000_indirect_call_template_1 test for
rs6000_pcrel_p() and then output b or bl opcodes without any subsequence
instruction.  This test mirrors those.



>> +  else if (DEFAULT_ABI == ABI_V4)
>> +return 0;
>> +  else if (DEFAULT_ABI == ABI_DARWIN)
>> +return 0;
>> +  else
>> +return 0;
>> +}

> The first two of these are superfluous.

Of course.  But mirroring the structure of the corresponding code makes
it easier to understand, and to check that the correspondence is there.
But now that style aspect is irrelevant, it's obviated by your suggested
alternate implementation.

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask 

Re: [PATCH] [testsuite] test for weak_undefined support and add options

[Alexandre Oliva via Gcc-patches]

On Mar 15, 2023, Alexandre Oliva  wrote:

> Regstrapped on ppc64-linux-gnu.  Also tested (with gcc-12) on multiple
> *-vxworks7r2 targets (arm, aarch64, ppc64, x86, x86_64).  Ok to install?

Further testing revealed a problem in my attempted use of lappend in
aapcs64.exp, in the previous version of the patch.  Fixed in this one,
retested on aarch64-vxworks7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (add_options_for_weak_undefined):
New.
(check_effective_target_weak_undefined): Use it.
(check_effective_target_posix_memalign): New.
* gcc.dg/torture/pr53922.c: Drop skips and custom options in
favor of effective target requirement and added options for
weak_undefined symbols.
* gcc.dg/torture/pr90020.c: Likewise.
* gcc.dg/addr_equal-1.c: Likewise.
* gcc.target/aarch64/aapcs64/aapcs64.exp: Likewise, for
abitest.S-using tests.
* gcc.dg/torture/pr60092.c: Likewise, but in favor of
posix_memalign tests.
* gcc.dg/vect/vect-tail-nomask-1.c: Likewise.
---
 gcc/testsuite/gcc.dg/addr_equal-1.c|5 ++--
 gcc/testsuite/gcc.dg/torture/pr53922.c |   10 ++--
 gcc/testsuite/gcc.dg/torture/pr60092.c |   12 ++---
 gcc/testsuite/gcc.dg/torture/pr90020.c |7 ++---
 gcc/testsuite/gcc.dg/vect/vect-tail-nomask-1.c |   11 ++--
 .../gcc.target/aarch64/aapcs64/aapcs64.exp |   17 -
 gcc/testsuite/lib/target-supports.exp  |   26 ++--
 7 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/addr_equal-1.c 
b/gcc/testsuite/gcc.dg/addr_equal-1.c
index 35fa0102e3063..db65dea4a8d2a 100644
--- a/gcc/testsuite/gcc.dg/addr_equal-1.c
+++ b/gcc/testsuite/gcc.dg/addr_equal-1.c
@@ -1,9 +1,8 @@
-/* { dg-do run { target { nonpic || pie_enabled } } } */
-/* { dg-require-weak "" } */
+/* { dg-do run { target { { nonpic || pie_enabled } && weak_undefined } } } */
 /* { dg-require-alias "" } */
 /* { dg-options "-O2 -fdelete-null-pointer-checks" } */
-/* { dg-skip-if "" { powerpc-ibm-aix* } } */
 /* { dg-skip-if "function pointers can be NULL" { keeps_null_pointer_checks } 
} */
+/* { dg-add-options weak_undefined } */
 void abort (void);
 extern int undef_var0, undef_var1;
 extern __attribute__ ((weak)) int weak_undef_var0;
diff --git a/gcc/testsuite/gcc.dg/torture/pr53922.c 
b/gcc/testsuite/gcc.dg/torture/pr53922.c
index b3f2c1a58f830..07359d6764964 100644
--- a/gcc/testsuite/gcc.dg/torture/pr53922.c
+++ b/gcc/testsuite/gcc.dg/torture/pr53922.c
@@ -1,11 +1,5 @@
-/* { dg-do run } */
-/* { dg-require-weak "" } */
-/* { dg-skip-if "No undefined" { *-*-mingw* } } */
-/* { dg-skip-if "No undefined weak" { *-*-aix* } } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* && { ! lp64 } } } */
-/* { dg-skip-if "No undefined weak" { nvptx-*-* } } */
-/* { dg-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* } } */
-/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } } 
*/
+/* { dg-do run { target { weak_undefined } } } */
+/* { dg-add-options weak_undefined } */
 
 int x(int a)
 {
diff --git a/gcc/testsuite/gcc.dg/torture/pr60092.c 
b/gcc/testsuite/gcc.dg/torture/pr60092.c
index 74e7c174a8323..102ba6e0d9f87 100644
--- a/gcc/testsuite/gcc.dg/torture/pr60092.c
+++ b/gcc/testsuite/gcc.dg/torture/pr60092.c
@@ -1,12 +1,7 @@
-/* { dg-do run } */
-/* { dg-require-weak "" } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* && { ! lp64 } } } */
-/* { dg-skip-if "No undefined weak" { nvptx-*-* } } */
-/* { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
*-*-darwin* } } */
-/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } } 
*/
+/* { dg-do run { target { posix_memalign } } } */
 
 typedef __SIZE_TYPE__ size_t;
-extern int posix_memalign(void **memptr, size_t alignment, size_t size) 
__attribute__((weak));
+extern int posix_memalign(void **memptr, size_t alignment, size_t size);
 extern void abort(void);
 int
 main (void)
@@ -14,9 +9,6 @@ main (void)
   void *p;
   int ret;
 
-  if (!posix_memalign)
-return 0;
-
   p = (void *)
   ret = posix_memalign (, sizeof (void *), -1);
   if (p != (void *))
diff --git a/gcc/testsuite/gcc.dg/torture/pr90020.c 
b/gcc/testsuite/gcc.dg/torture/pr90020.c
index 657c4ccfe45c4..40035aa758e6e 100644
--- a/gcc/testsuite/gcc.dg/torture/pr90020.c
+++ b/gcc/testsuite/gcc.dg/torture/pr90020.c
@@ -1,8 +1,5 @@
-/* { dg-do run } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* || powerpc-ibm-aix* } } */
-/* { dg-require-weak "" } */
-/* { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
*-*-darwin* } } */
-/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } } 
*/
+/* { dg-do run  { target { weak_undefined } } } */
+/* { dg-add-options weak_undefined } */
 
 void __attribute__((noinline,noclone))
 check (int i)
diff --git 

[PATCH] [testsuite] fix array element count

[Alexandre Oliva via Gcc-patches]

This test is similar to pr103116-1.c, but instead of writing to
4*COUNT elements of x, it writes to 8*COUNT elements, but the
definition of x seems to have been adjusted along with the loop.  Fix
the array size so that it doesn't scribble over unrelated
statically-allocated objects.

Regstrapped on ppc64-linux-gnu.  Also tested with gcc-11 on vxworks7r2
(x86- and x86_64-), where the scribbling caused visible runtime effects.
Ok to install?  I'm tempted to put this in as obvious.


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/pr103116-2.c (x): Fix array size.
---
 gcc/testsuite/gcc.dg/vect/pr103116-2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/vect/pr103116-2.c 
b/gcc/testsuite/gcc.dg/vect/pr103116-2.c
index 2f4ed0f404c76..aa9797a94074c 100644
--- a/gcc/testsuite/gcc.dg/vect/pr103116-2.c
+++ b/gcc/testsuite/gcc.dg/vect/pr103116-2.c
@@ -31,7 +31,7 @@ loop (TYPE *restrict x, TYPE *restrict y)
 }
 }
 
-TYPE x[COUNT * 4];
+TYPE x[COUNT * 8];
 
 int
 main (void)

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [testsuite] test for weak_undefined support and add options

[Alexandre Oliva via Gcc-patches]

A number of tests that depend on weak undefined symbols fail to
require that support, and arrange to skip some targets and add special
options to others on a test-by-test basis.  Fix this by stating the
requirement explicitly, and adding a proc to return any required
options.

Others rely on weak undefined symbols only to test for the
availability of posix_memalign.  Drop that in favor of dg effective
target support for posix_memalign.

Regstrapped on ppc64-linux-gnu.  Also tested (with gcc-12) on multiple
*-vxworks7r2 targets (arm, aarch64, ppc64, x86, x86_64).  Ok to install?


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (add_options_for_weak_undefined):
New.
(check_effective_target_weak_undefined): Use it.
(check_effective_target_posix_memalign): New.
* gcc.dg/torture/pr53922.c: Drop skips and custom options in
favor of effective target requirement and added options for
weak_undefined symbols.
* gcc.dg/torture/pr90020.c: Likewise.
* gcc.dg/addr_equal-1.c: Likewise.
* gcc.target/aarch64/aapcs64/aapcs64.exp: Likewise, for
abitest.S-using tests.
* gcc.dg/torture/pr60092.c: Likewise, but in favor of
posix_memalign tests.
* gcc.dg/vect/vect-tail-nomask-1.c: Likewise.
---
 gcc/testsuite/gcc.dg/addr_equal-1.c|5 ++--
 gcc/testsuite/gcc.dg/torture/pr53922.c |   10 ++--
 gcc/testsuite/gcc.dg/torture/pr60092.c |   12 ++---
 gcc/testsuite/gcc.dg/torture/pr90020.c |7 ++---
 gcc/testsuite/gcc.dg/vect/vect-tail-nomask-1.c |   11 ++--
 .../gcc.target/aarch64/aapcs64/aapcs64.exp |   17 -
 gcc/testsuite/lib/target-supports.exp  |   26 ++--
 7 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/addr_equal-1.c 
b/gcc/testsuite/gcc.dg/addr_equal-1.c
index 35fa0102e3063..db65dea4a8d2a 100644
--- a/gcc/testsuite/gcc.dg/addr_equal-1.c
+++ b/gcc/testsuite/gcc.dg/addr_equal-1.c
@@ -1,9 +1,8 @@
-/* { dg-do run { target { nonpic || pie_enabled } } } */
-/* { dg-require-weak "" } */
+/* { dg-do run { target { { nonpic || pie_enabled } && weak_undefined } } } */
 /* { dg-require-alias "" } */
 /* { dg-options "-O2 -fdelete-null-pointer-checks" } */
-/* { dg-skip-if "" { powerpc-ibm-aix* } } */
 /* { dg-skip-if "function pointers can be NULL" { keeps_null_pointer_checks } 
} */
+/* { dg-add-options weak_undefined } */
 void abort (void);
 extern int undef_var0, undef_var1;
 extern __attribute__ ((weak)) int weak_undef_var0;
diff --git a/gcc/testsuite/gcc.dg/torture/pr53922.c 
b/gcc/testsuite/gcc.dg/torture/pr53922.c
index b3f2c1a58f830..07359d6764964 100644
--- a/gcc/testsuite/gcc.dg/torture/pr53922.c
+++ b/gcc/testsuite/gcc.dg/torture/pr53922.c
@@ -1,11 +1,5 @@
-/* { dg-do run } */
-/* { dg-require-weak "" } */
-/* { dg-skip-if "No undefined" { *-*-mingw* } } */
-/* { dg-skip-if "No undefined weak" { *-*-aix* } } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* && { ! lp64 } } } */
-/* { dg-skip-if "No undefined weak" { nvptx-*-* } } */
-/* { dg-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* } } */
-/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } } 
*/
+/* { dg-do run { target { weak_undefined } } } */
+/* { dg-add-options weak_undefined } */
 
 int x(int a)
 {
diff --git a/gcc/testsuite/gcc.dg/torture/pr60092.c 
b/gcc/testsuite/gcc.dg/torture/pr60092.c
index 74e7c174a8323..102ba6e0d9f87 100644
--- a/gcc/testsuite/gcc.dg/torture/pr60092.c
+++ b/gcc/testsuite/gcc.dg/torture/pr60092.c
@@ -1,12 +1,7 @@
-/* { dg-do run } */
-/* { dg-require-weak "" } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* && { ! lp64 } } } */
-/* { dg-skip-if "No undefined weak" { nvptx-*-* } } */
-/* { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
*-*-darwin* } } */
-/* { dg-additional-options "-Wl,-flat_namespace" { target *-*-darwin[89]* } } 
*/
+/* { dg-do run { target { posix_memalign } } } */
 
 typedef __SIZE_TYPE__ size_t;
-extern int posix_memalign(void **memptr, size_t alignment, size_t size) 
__attribute__((weak));
+extern int posix_memalign(void **memptr, size_t alignment, size_t size);
 extern void abort(void);
 int
 main (void)
@@ -14,9 +9,6 @@ main (void)
   void *p;
   int ret;
 
-  if (!posix_memalign)
-return 0;
-
   p = (void *)
   ret = posix_memalign (, sizeof (void *), -1);
   if (p != (void *))
diff --git a/gcc/testsuite/gcc.dg/torture/pr90020.c 
b/gcc/testsuite/gcc.dg/torture/pr90020.c
index 657c4ccfe45c4..40035aa758e6e 100644
--- a/gcc/testsuite/gcc.dg/torture/pr90020.c
+++ b/gcc/testsuite/gcc.dg/torture/pr90020.c
@@ -1,8 +1,5 @@
-/* { dg-do run } */
-/* { dg-skip-if "No undefined weak" { hppa*-*-hpux* || powerpc-ibm-aix* } } */
-/* { dg-require-weak "" } */
-/* { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
*-*-darwin* } } */
-/* { dg-additional-options 

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

[Alexandre Oliva via Gcc-patches]

On Mar  8, 2023, Richard Biener  wrote:

> On Wed, Mar 8, 2023 at 2:04 PM Martin Liška  wrote:

>> Is the emitted warning correct?

> For the reduced testcase yes, if !aio_bh_poll_s (or !aio_bh_poll_bh)
> the stored pointer remains local.

*nod*, before the recent patch, it would have failed to issue the
warning in somewhat unpredictable circumstances.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Alexandre Oliva  wrote:

> Hello, Florian,
> On Mar  3, 2023, Florian Weimer  wrote:

>> * Alexandre Oliva via Gcc-patches:
>>> +// Make sure it's not optimized out, not even with LTO.
>>> +asm ("" : : "rm" (depend));

>> If the m constraint is used, this may never emit the symbol name and
>> thus not create a reference after all.

> But that is no longer the pthread symbol itself, it's the symbol of a
> static member function with vague linkage that, because the compiler
> believes the asm statement will reference it, will still be output, and
> it's that function body that will refer to and thus pull in the symbols
> we need.

> Now, hmm, maybe with per-function sections, the compiler will emit it,
> but with section gc, the linker may drop it, so we might lose the needed
> function body.  When performing LTO with an LTO-enabled libstdc++.

Wait, no, you had me going but it's really fine.  What would be in
memory is a *pointer* to the function, so the function would still be
referenced by whatever initialized the pointer, so it wouldn't get GCed.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

Hello, Florian,

On Mar  3, 2023, Florian Weimer  wrote:

> * Alexandre Oliva via Gcc-patches:
>> +// Make sure it's not optimized out, not even with LTO.
>> +asm ("" : : "rm" (depend));

> If the m constraint is used, this may never emit the symbol name and
> thus not create a reference after all.

But that is no longer the pthread symbol itself, it's the symbol of a
static member function with vague linkage that, because the compiler
believes the asm statement will reference it, will still be output, and
it's that function body that will refer to and thus pull in the symbols
we need.

Now, hmm, maybe with per-function sections, the compiler will emit it,
but with section gc, the linker may drop it, so we might lose the needed
function body.  When performing LTO with an LTO-enabled libstdc++.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: [PATCH] libstdc++: testsuite: async.cc early timeout

[Alexandre Oliva via Gcc-patches]

On Feb  3, 2023, Jonathan Wakely  wrote:

> This one slipped through the cracks, sorry.

Oh, nice, thanks, I'd missed the review too, for a whole month :-)

I've just found the unread message.  I'll have a happier weekend.  I did
not even recall this patch was still pending, and this very test was the
one remaining issue for which I got occasional fails on
arm-vx7r2/gcc-12, and I still hadn't started looking into it.

We may still have other fails in this test (we used to have two
different fail modes in async.cc, the other is probably yet to be
upstreamed, but it was just an xfail), but this is progress :-)

> The patch is OK for trunk now (and should still apply cleanly).

Thanks, I'm checking it in now.

>> for  libstdc++-v3/ChangeLog
>> 
>> * testsuite/30_threads/async/async.cc (test04): Initialize
>> steady_start, renamed from steady_begin, next to slow_start.
>> Increase tolerance for final wait.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Jonathan Wakely  wrote:

> On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely  wrote:

>> And those expressions aren't ever optimized away as unused?

> Oh, I missed that they're called after casting them

*nod*

> That would be UB to call them through the wrong pointer type, so the
> compiler could decide they're unreachable

Ugh, indeed.  We can drop the cast and add the required parameters if it
ever becomes an issue.  Here's what I've just installed.


link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
---
 libstdc++-v3/include/bits/std_thread.h |   24 +---
 libstdc++-v3/src/c++11/thread.cc   |   10 --
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_thread.h 
b/libstdc++-v3/include/bits/std_thread.h
index adbd3928ff783..e88c07fbd4f0f 100644
--- a/libstdc++-v3/include/bits/std_thread.h
+++ b/libstdc++-v3/include/bits/std_thread.h
@@ -132,6 +132,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 thread() noexcept = default;
 
 #ifdef _GLIBCXX_HAS_GTHREADS
+  private:
+// This adds to user code that creates std:thread objects (because
+// it is called by the template ctor below) strong references to
+// pthread_create and pthread_join, which ensures they are both
+// linked in even during static linking.  We can't depend on
+// gthread calls to bring them in, because those may use weak
+// references.
+static void
+_M_thread_deps_never_run() {
+#ifdef GTHR_ACTIVE_PROXY
+  reinterpret_cast(_create)();
+  reinterpret_cast(_join)();
+#endif
+}
+
+  public:
 template>>
   explicit
@@ -142,18 +158,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  "std::thread arguments must be invocable after conversion to rvalues"
  );
 
-#ifdef GTHR_ACTIVE_PROXY
-   // Create a reference to pthread_create, not just the gthr weak symbol.
-   auto __depend = reinterpret_cast(_create);
-#else
-   auto __depend = nullptr;
-#endif
using _Wrapper = _Call_wrapper<_Callable, _Args...>;
// Create a call wrapper with DECAY_COPY(__f) as its target object
// and DECAY_COPY(__args)... as its bound argument entities.
_M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
  std::forward<_Callable>(__f), std::forward<_Args>(__args)...)),
-   __depend);
+   _M_thread_deps_never_run);
   }
 #endif // _GLIBCXX_HAS_GTHREADS
 
diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 2d5ffaf678e97..c91f7b02e1f3f 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -154,8 +154,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   void
-  thread::_M_start_thread(_State_ptr state, void (*)())
+  thread::_M_start_thread(_State_ptr state, void (*depend)())
   {
+// Make sure it's not optimized out, not even with LTO.
+asm ("" : : "rm" (depend));
+
 if (!__gthread_active_p())
   {
 #if __cpp_exceptions
@@ -190,8 +193,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   void
-  thread::_M_start_thread(__shared_base_type __b, void (*)())
+  thread::_M_start_thread(__shared_base_type __b, void (*depend)())
   {
+// Make sure it's not optimized out, not even with LTO.
+asm ("" : : "rm" (depend));
+
 auto ptr = __b.get();
 // Create a reference cycle that will be broken in the new thread.
 ptr->_M_this_ptr = std::move(__b);


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] [rs6000] adjust return_pc debug attrs

[Alexandre Oliva via Gcc-patches]

Some of the rs6000 call patterns, on some ABIs, issue multiple opcodes
out of a single call insn, but the call (bl) or jump (b) is not always
the last opcode in the sequence.

This does not seem to be a problem for exception handling tables, but
the return_pc attribute in the call graph output in dwarf2+ debug
information, that takes the address of a label output right after the
call, does not match the value of the link register even for non-tail
calls.  E.g., with ABI_AIX or ABI_ELFv2, such code as:

  foo ();

outputs:

  bl foo
  nop
 LVL#:
[...]
  .8byte .LVL#  # DW_AT_call_return_pc

but debug info consumers may rely on the return_pc address, and draw
incorrect conclusions from its off-by-4 value.

This patch introduces infrastructure for targets to add an offset to
the label issued after the call_insn to set the call_return_pc
attribute, and uses that on rs6000 to account for nop and l opcodes
issued after actual call opcode as part of call insns output patterns.


for  gcc/ChangeLog

* target.def (call_offset_return_label): New hook.
* gcc/doc/tm.texi.in (TARGET_CALL_OFFSET_RETURN_LABEL): Add
placeholder.
* gcc/doc/tm.texi: Rebuild.
* dwarf2out.cc (struct call_arg_loc_node): Record call_insn
instad of call_arg_loc_note.
(add_AT_lbl_id): Add optional offset argument.
(gen_call_site_die): Compute and pass on a return pc offset.
(gen_subprogram_die): Move call_arg_loc_note computation...
(dwarf2out_var_location): ... from here.  Set call_insn.
* config/rs6000/rs6000.cc (TARGET_CALL_OFFSET_RETURN_LABEL):
Override.
(rs6000_call_offset_return_label): New.
* config/rs6000/rs6000.md (call_needs_return_offset): New
attribute.  Set it on call patterns that may require
offsetting.
---
 gcc/config/rs6000/rs6000.cc |   37 +
 gcc/config/rs6000/rs6000.md |   24 
 gcc/doc/tm.texi |7 +++
 gcc/doc/tm.texi.in  |2 ++
 gcc/dwarf2out.cc|   26 +-
 gcc/target.def  |9 +
 6 files changed, 96 insertions(+), 9 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 8e0b0d022db2f..edbc7a011886c 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -1760,6 +1760,9 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 
 #undef TARGET_UPDATE_IPA_FN_TARGET_INFO
 #define TARGET_UPDATE_IPA_FN_TARGET_INFO rs6000_update_ipa_fn_target_info
+
+#undef TARGET_CALL_OFFSET_RETURN_LABEL
+#define TARGET_CALL_OFFSET_RETURN_LABEL rs6000_call_offset_return_label
 
 
 /* Processor table.  */
@@ -14593,6 +14596,40 @@ rs6000_assemble_integer (rtx x, unsigned int size, int 
aligned_p)
   return default_assemble_integer (x, size, aligned_p);
 }
 
+/* Return the offset to be added to the label output after CALL_INSN
+   to compute the address to be placed in DW_AT_call_return_pc.  Some
+   call insns output nop or l after bl, so the return address would be
+   wrong without this offset.  */
+
+static int
+rs6000_call_offset_return_label (rtx_insn *call_insn)
+{
+  /* We don't expect SEQUENCEs in this port.  */
+  gcc_checking_assert (GET_CODE (call_insn) == CALL_INSN);
+
+  enum attr_call_needs_return_offset cnro
+= get_attr_call_needs_return_offset (call_insn);
+
+  if (cnro == CALL_NEEDS_RETURN_OFFSET_NONE)
+return 0;
+
+  if (rs6000_pcrel_p ())
+return 0;
+  else if (DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
+/* rs6000_call_template_1 outputs a nop after non-sibcall insns;
+   we mark sibcall insns with NONE rather than DIRECT, so we
+   should have returned zero above.
+   rs6000_indirect_call_template_1 outputs an l insn after
+   indirect calls in these ABIs.  */
+return -4;
+  else if (DEFAULT_ABI == ABI_V4)
+return 0;
+  else if (DEFAULT_ABI == ABI_DARWIN)
+return 0;
+  else
+return 0;
+}
+
 /* Return a template string for assembly to emit when making an
external call.  FUNOP is the call mem argument operand number.  */
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 81bffb04ceb0c..7dc73b21af731 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -342,6 +342,12 @@ (define_attr "max_prefixed_insns" "" (const_int 1))
 ;; num_insns and recurse).
 (define_attr "length" "" (const_int 4))
 
+;; Calls that output insns after bl need DW_AT_call_return_pc to be
+;; adjusted.  rs6000_call_offset_return_label uses this attribute to
+;; conservatively recognize the relevant patterns.
+(define_attr "call_needs_return_offset" "none,direct,indirect"
+  (const_string "none"))
+
 ;; Processor type -- this attribute must exactly match the processor_type
 ;; enumeration in rs6000-opts.h.
 (define_attr "cpu"
@@ -11355,6 +11361,7 @@ (define_insn "*call_indirect_nonlocal_sysv"
   return 

[PATCH] [libstdc++] [prettyprint] add local std::string use to more tests

[Alexandre Oliva via Gcc-patches]

We're getting regressions after ugprading to GDB 13 in a few of the
libstdc++ pretty-printing tests.  It might seem like a GDB regression,
but that update has a new symbol reader, and Tom Tromey says it
exposes a latent problem in the pretty-printer, namely, when a name is
not defined locally in the local translation unit, GDB will look for
it in other units, and if multiple different definitions are
available, there are no guarantees as to which one it will find.

Since libstdc++ contains units in which std::string maps to different
types, in order to ensure the tests get the std::string definition we
expect, we need std::string to be present in the debug information for
the test itself, as we already do in other tests.

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


for  libstdc++-v3/ChangeLog

* testsuite/libstdc++-pretty-printers/80276.cc: Add
std::string to debug info.
* testsuite/libstdc++-pretty-printers/libfundts.cc: Likewise.


Change-Id: I928617d44679c63d634c26f6db17d7580a9bcd8f
TN: W223-034
---
 .../testsuite/libstdc++-prettyprinters/80276.cc|5 +
 .../libstdc++-prettyprinters/libfundts.cc  |6 ++
 2 files changed, 11 insertions(+)

diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
index db4de593808e3..1d6b0207106a6 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
@@ -36,6 +36,11 @@ int
 main()
 {
   using namespace std;
+  // Ensure debug info for std::string is issued in the local
+  // translation unit, so that GDB won't pick up any alternate
+  // std::string notion that might be present in libstdc++.so.
+  string bah = "hi";
+  (void)bah;
   unique_ptr*>>> p1;
   unique_ptr*>>[]> p2;
   unique_ptr*>>[10]> p3;
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc
index b1c91033cc8e6..29e8bc8f194e3 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/libfundts.cc
@@ -32,6 +32,12 @@ using std::experimental::string_view;
 int
 main()
 {
+  // Ensure debug info for std::string is issued in the local
+  // translation unit, so that GDB won't pick up any alternate
+  // std::string notion that might be present in libstdc++.so.
+  std::string bah = "hi";
+  (void)bah;
+
   string_view str = "string";
 // { dg-final { note-test str "\"string\"" } }
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Jonathan Wakely  wrote:

> On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely  wrote:
>> Jakub previously suggested doing this for PR 61841, which was a similar
>> problem with pthread_create:
>> 
>> __asm ("" : : "r" (_create)); would not be optimized away.
>> 
>> 
>> That would avoid the multiple copies.

Not really.  There would be multiple copies of the code that loads
pthread_create's address.  And we don't really need the address, a
single never-executed call would do.  I've explored these possibilities
a bit, and here's what I've come up with: a private static member
function that we output in units that instantiate the thread template
ctor, to pass its address to _M_start_thread.  Since it's never actually
called, we don't really need the hacks in some of the alternatives I
left in place, mainly for your enjoyment.

They all work equally well, just as efficient per-instantiation at
runtime, a little different space and loading overheads, but the last
one, that is enabled, is my favorite: only PLT relocations, that we'd
likely get anyway, no full-address resolution, and as-short-as-possible
calls, enough to get a relocation with a strong reference to pull the
symbol in when linking, but as short as possible call sequences, because
of the type cast.

As a bonus, I put in (in the last minute, after my test runs) something
to keep even LTO happy: the asm statements to prevent depend from being
optimized out in _M_start_thread.  In non-LTO, its impact should be
virtually zero.

How does this look?  (minus the #if 0/#elif 0/.../#else)


link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

* include/bits/std_thread.h (thread::_M_thread_deps): New
static inline function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
---
 libstdc++-v3/include/bits/std_thread.h |   51 
 libstdc++-v3/src/c++11/thread.cc   |   10 +-
 2 files changed, 52 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_thread.h 
b/libstdc++-v3/include/bits/std_thread.h
index adbd3928ff783..3ffd2a823a698 100644
--- a/libstdc++-v3/include/bits/std_thread.h
+++ b/libstdc++-v3/include/bits/std_thread.h
@@ -132,6 +132,49 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 thread() noexcept = default;
 
 #ifdef _GLIBCXX_HAS_GTHREADS
+  private:
+// This adds to user code that creates std:thread objects (because
+// it is called by the template ctor below) strong references to
+// pthread_create and pthread_join, which ensures they are both
+// linked in even during static linking.  We can't depend on
+// gthread calls to bring them in, because those may use weak
+// references.
+static void
+_M_thread_deps_never_run() {
+#ifdef GTHR_ACTIVE_PROXY
+#if 0
+  static auto const __attribute__ ((__used__)) _M_create = pthread_create;
+  static auto const __attribute__ ((__used__)) _M_join = pthread_join;
+#elif 0
+  pthread_t thr;
+  pthread_create (, nullptr, nullptr, nullptr);
+  pthread_join (thr, nullptr);
+#elif 0
+  asm goto ("" : : : : _M_never_run);
+  if (0)
+   {
+   _M_never_run:
+ pthread_t thr;
+ pthread_create (, nullptr, nullptr, nullptr);
+ pthread_join (thr, nullptr);
+   }
+#elif 0
+  bool _M_skip_always = false;
+  asm ("" : "+rm" (_M_skip_always));
+  if (__builtin_expect (_M_skip_always, false))
+   {
+ pthread_t thr;
+ pthread_create (, nullptr, nullptr, nullptr);
+ pthread_join (thr, nullptr);
+   }
+#else
+  reinterpret_cast(_create)();
+  reinterpret_cast(_join)();
+#endif
+#endif
+}
+
+  public:
 template>>
   explicit
@@ -142,18 +185,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  "std::thread arguments must be invocable after conversion to rvalues"
  );
 
-#ifdef GTHR_ACTIVE_PROXY
-   // Create a reference to pthread_create, not just the gthr weak symbol.
-   auto __depend = reinterpret_cast(_create);
-#else
-   auto __depend = nullptr;
-#endif
using _Wrapper = _Call_wrapper<_Callable, _Args...>;
// Create a call wrapper with DECAY_COPY(__f) as its target object
// and DECAY_COPY(__args)... as its bound argument entities.
_M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
  std::forward<_Callable>(__f), std::forward<_Args>(__args)...)),
-   __depend);
+   _M_thread_deps_never_run);
   }
 #endif // _GLIBCXX_HAS_GTHREADS
 
diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 2d5ffaf678e97..c91f7b02e1f3f 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ 

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Richard Biener  wrote:

>> * gimple-ssa-warn-access.cc
>> (pass_waccess::check_dangling_stores): Skip non-stores.
>> 
>> for  gcc/testsuite/ChangeLog
>> 
>> * g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
>> two new variants, one fixed, one xfailed.
>> * c-c++-common/Wdangling-pointer-5.c
>> (nowarn_store_arg_store_arg): Add now-expected warnings.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612186.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [arm] adjust expectations for armv8_2-fp16-move-[12].c

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Alexandre Oliva  wrote:

>   * gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe
>   expected counts into a single pattern.
>   * gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional
>   return and reversed conditions.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612190.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR51534] [arm] split out pr51534 test for softfp

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Alexandre Oliva  wrote:

>   PR target/51534
>   * gcc.target/arm/pr51534.c: Split softfp variant into...
>   * gcc.target/arm/pr51534s.c: ... this, and support ARM too.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612189.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [arm] complete vmsr/vmrs blank and case adjustments

[Alexandre Oliva via Gcc-patches]

On Feb 20, 2023, Andrea Corallo via Gcc-patches  wrote:

> Alexandre Oliva  writes:
>> Back in September last year, some of the vmsr and vmrs patterns had an
>> extraneous blank removed, and the case of register names lowered, but
>> another instance remained, and so did a few testcases.

> I'm not approver but LGTM, thanks for fixing this.

Ping on this one as well.
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612192.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR104882] [arm] require mve hw for mve run test

[Alexandre Oliva via Gcc-patches]

On Feb 20, 2023, Andrea Corallo  wrote:

> Alexandre Oliva via Gcc-patches  writes:
>> PR target/104882
>> * gcc.target/arm/simd/pr104882.c: Require mve hardware.

> no approver here but LGTM, thanks.

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612194.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

[Alexandre Oliva via Gcc-patches]

Hello, Christophe,

On Feb 22, 2023, Christophe Lyon  wrote:

> OK thanks for the clarification.

> (and for the other cleanup patches!)

Was this meant as approval?  I hadn't taken it as such.

Otherwise, please consider this a ping :-)
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612188.html

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Jonathan Wakely  wrote:

> The proper fix is to ensure the program has a non-weak reference to
> pthread_join without extra help (or use a recent glibc where it always
> works).

Indeed!  How about this?  Regstrapped on x86_64-linux-gnu, also tested
on arm-vx7r2 (gcc-12); verified that strong references are present in
95989.o, but not in libstdc++.a or .so.  Ok to install?

(nit: the static local in a ctor of a template class may make for
multiple copies.  Maybe a non-template always-inline function called by
all instantiations would be better.)


link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

* include/bits/std_thread.h (std::thread ctor): Add strong
reference to pthread_join.

---
 libstdc++-v3/include/bits/std_thread.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/include/bits/std_thread.h 
b/libstdc++-v3/include/bits/std_thread.h
index adbd3928ff783..4bda350fa2c7b 100644
--- a/libstdc++-v3/include/bits/std_thread.h
+++ b/libstdc++-v3/include/bits/std_thread.h
@@ -145,6 +145,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #ifdef GTHR_ACTIVE_PROXY
// Create a reference to pthread_create, not just the gthr weak symbol.
auto __depend = reinterpret_cast(_create);
+   static auto __attribute__((__used__)) __depend_join = _join;
 #else
auto __depend = nullptr;
 #endif


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

[Alexandre Oliva via Gcc-patches]

On Feb 24, 2023, Richard Earnshaw  wrote:

> Given the logic of this macro, the text should be
> "!TARGET_CXX_METHOD_MAY_BE_INLINE".

I was thinking just "related to that macro", but yeah, negating it makes
sense.

> OK with that change.

Thanks, here's what I'm checking in.


[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods

From: Alexandre Oliva 

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way
the clash between AAPCS and C++ Modules design should be resolved, but
currently it favors AAPCS and thus the test fails, so skip it on
arm_eabi.


for  gcc/testsuite/ChangeLog

PR c++/105224
* g++.dg/modules/virt-2_a.C: Skip on arm_eabi.
---
 gcc/testsuite/g++.dg/modules/virt-2_a.C |3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/testsuite/g++.dg/modules/virt-2_a.C 
b/gcc/testsuite/g++.dg/modules/virt-2_a.C
index 580552be5a0d8..b5050445c3f15 100644
--- a/gcc/testsuite/g++.dg/modules/virt-2_a.C
+++ b/gcc/testsuite/g++.dg/modules/virt-2_a.C
@@ -1,3 +1,6 @@
+// AAPCS overrides TARGET_CXX_KEY_METHOD_MAY_BE_INLINE,
+// in a way that invalidates this test.
+// { dg-skip-if "!TARGET_CXX_KEY_METHOD_MAY_BE_INLINE" { arm_eabi } } 
 // { dg-module-do run }
 // { dg-additional-options -fmodules-ts }
 export module foo;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

[Alexandre Oliva via Gcc-patches]

On Feb 23, 2023, Alexandre Oliva  wrote:

> On Feb 23, 2023, Richard Earnshaw  wrote:
>> On 22/02/2023 19:57, Alexandre Oliva wrote:
>>> On Feb 21, 2023, Richard Earnshaw  wrote:
>>> 
 Rather than scanning for the triplet, a better test would be
>>> 
 { xfail { arm_eabi } }
>>> 
>>> Indeed, thanks.  Here's the updated patch, retested.  Ok to install?

>> Based on Nathan's comments, we should just skip the test on arm_eabi,
>> it's simply not applicable.

> Like this, I suppose.  Retested on x86_64-linux-gnu (trunk) and
> arm-wrs-vxworks7 (gcc-12).  Ok to install?

Erhm, actually, that version still ran the assembler scans and failed.
This one skips the testset entirely.


[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods

From: Alexandre Oliva 

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way
the clash between AAPCS and C++ Modules design should be resolved, but
currently it favors AAPCS and thus the test fails, so skip it on
arm_eabi.


for  gcc/testsuite/ChangeLog

PR c++/105224
* g++.dg/modules/virt-2_a.C: Skip on arm_eabi.
---
 gcc/testsuite/g++.dg/modules/virt-2_a.C |3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/testsuite/g++.dg/modules/virt-2_a.C 
b/gcc/testsuite/g++.dg/modules/virt-2_a.C
index 580552be5a0d8..ede711c3e83be 100644
--- a/gcc/testsuite/g++.dg/modules/virt-2_a.C
+++ b/gcc/testsuite/g++.dg/modules/virt-2_a.C
@@ -1,3 +1,6 @@
+// AAPCS overrides TARGET_CXX_KEY_METHOD_MAY_BE_INLINE,
+// in a way that invalidates this test.
+// { dg-skip-if "TARGET_CXX_KEY_METHOD_MAY_BE_INLINE" { arm_eabi } } 
 // { dg-module-do run }
 // { dg-additional-options -fmodules-ts }
 export module foo;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

[Alexandre Oliva via Gcc-patches]

On Feb 22, 2023, Alexandre Oliva  wrote:

>> Just curious, why doesn't the pmf hack work on arm-vxworks7?

> At first, I thought we were running into this just because we have to
> define __clang__ because of some vxworks system headers aimed at clang.
> But even as I tried to drop the #ifndef, the test still failed; I
> suspected it had to do with ARM's encoding of ptrmemfunc_vbit_in_delta,
> but I did not confirm that this was the case.

It was much simpler than that: patching locale_facets_nonio.tcc did not
affect the code generated for the tests, even though the modified
definition was present in the preprocessed version, and the patch didn't
cause locale-inst.o to be rebuilt.


With a build from scratch, the following patchlet is enough for time_get
tests to pass for us, and I assume we'll have to keep on carrying such
local changes, but I wonder if it would make sense to submit a patch to
adjust all preprocessor tests for __clang__ in libstdc++ to also test
for __clang_major__.

--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
@@ -1465,7 +1465,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
   ctype<_CharT> const& __ctype = use_facet >(__loc);
   __err = ios_base::goodbit;
   bool __use_state = false;
-#if __GNUC__ >= 5 && !defined(__clang__)
+#if __GNUC__ >= 5 && !(defined(__clang__) && defined(__clang_major__))
 #pragma GCC diagnostic push
 #pragma GCC diagnostic ignored "-Wpmf-conversions"
   // Nasty hack.  The C++ standard mandates that get invokes the do_get


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

[Alexandre Oliva via Gcc-patches]

On Feb 23, 2023, Richard Earnshaw  wrote:

> On 22/02/2023 19:57, Alexandre Oliva wrote:
>> On Feb 21, 2023, Richard Earnshaw  wrote:
>> 
>>> Rather than scanning for the triplet, a better test would be
>> 
>>> { xfail { arm_eabi } }
>> 
>> Indeed, thanks.  Here's the updated patch, retested.  Ok to install?

> Based on Nathan's comments, we should just skip the test on arm_eabi,
> it's simply not applicable.

Like this, I suppose.  Retested on x86_64-linux-gnu (trunk) and
arm-wrs-vxworks7 (gcc-12).  Ok to install?


[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods

From: Alexandre Oliva 

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way
the clash between AAPCS and C++ Modules design should be resolved, but
currently it favors AAPCS and thus the test fails, so skip it on
arm_eabi.


for  gcc/testsuite/ChangeLog

PR c++/105224
* g++.dg/modules/virt-2_a.C: Skip on arm_eabi.
---
 gcc/testsuite/g++.dg/modules/virt-2_a.C |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/modules/virt-2_a.C 
b/gcc/testsuite/g++.dg/modules/virt-2_a.C
index 580552be5a0d8..8fa42d97d72d7 100644
--- a/gcc/testsuite/g++.dg/modules/virt-2_a.C
+++ b/gcc/testsuite/g++.dg/modules/virt-2_a.C
@@ -1,4 +1,6 @@
-// { dg-module-do run }
+// AAPCS overrides TARGET_CXX_KEY_METHOD_MAY_BE_INLINE,
+// in a way that invalidates this test.
+// { dg-module-do run { target { ! arm_eabi } } }
 // { dg-additional-options -fmodules-ts }
 export module foo;
 // { dg-module-cmi foo }


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PR100127] Test for coroutine header in clang-compatible tests

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Iain Sandoe  wrote:

> As a matter of interest, do you know of any other compiler claiming 
> “__clang__” (I have
> treated that as safe so far).

We've had (or found it more convenient, not sure) to do that to gcc on
some recent combinations of version and target of vxworks, for one.

>> Use a __has_include feature test instead.

> I think we need to do

> #if __has_include()
> …
> #elif __has_include()
> …

> because newer clang has the include in the standard place.

That would change what gets tested with clang, I suppose, but I hope
that's for the better.  I wondered what to do at the #else above, and
decided to spell it a little differently.  Retested on x86_64-linux-gnu
(trunk) and arm-vxworks7r2 (gcc-12), ok to install?


[PR100127] Test for coroutine header in clang-compatible tests

From: Alexandre Oliva 

The test is compatible with clang as well as gcc, but ISTM that
testing for the __clang__ macro is just as potentially error-prone as
macros that used to be GCC-specific are now defined in compilers that
aim for GCC compatibility.  Use a __has_include feature test instead.


for  gcc/testsuite/ChangeLog

PR c++/100127
* g++.dg/coroutines/pr100127.C: Test for header rather than
compiler macro.
---
 gcc/testsuite/g++.dg/coroutines/pr100127.C   |3 ++-
 gcc/testsuite/g++.dg/coroutines/pr100772-a.C |3 ++-
 gcc/testsuite/g++.dg/coroutines/pr100772-b.C |3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/pr100127.C 
b/gcc/testsuite/g++.dg/coroutines/pr100127.C
index 374cd710077af..5879fd0bcc595 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr100127.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr100127.C
@@ -1,4 +1,5 @@
-#ifdef __clang__
+#if !__has_include() \
+  && __has_include() // for __clang__
 #include 
 namespace std {
   using namespace std::experimental;
diff --git a/gcc/testsuite/g++.dg/coroutines/pr100772-a.C 
b/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
index a325d384fc390..06e705b0c65a0 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
@@ -1,5 +1,6 @@
 //  { dg-additional-options "-fsyntax-only " }
-#ifdef __clang__
+#if !__has_include() \
+  && __has_include() // for __clang__
 #include 
 namespace std {
   using namespace std::experimental;
diff --git a/gcc/testsuite/g++.dg/coroutines/pr100772-b.C 
b/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
index 6cdf8d1e529e5..4ef80a9959490 100644
--- a/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
+++ b/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
@@ -1,4 +1,5 @@
-#ifdef __clang__
+#if !__has_include() \
+  && __has_include() // for __clang__
 #include 
 namespace std {
   using namespace std::experimental;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about