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

2023-03-22 Thread oliva--- via Gcc-patches
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. Regstrapped on x86_64-linux-gnu and

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

2023-05-29 Thread 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

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

2023-06-02 Thread 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 com

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

2023-06-02 Thread 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

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

2023-06-02 Thread 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

[testsuite] bump some tsvc timeouts

2023-06-07 Thread 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: Li

[PATCH] fix frange_nextafter odr violation

2023-06-08 Thread 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-flo

Re: [PATCH] fix frange_nextafter odr violation

2023-06-09 Thread 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-r

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

2023-06-14 Thread 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

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

2023-06-14 Thread 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/f

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

2023-06-14 Thread 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/entro

Re: [PATCH] Introduce hardbool attribute for C

2023-06-15 Thread 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,

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

2023-06-16 Thread 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, inste

[PATCH v3] Introduce attribute reverse_alias

2023-07-14 Thread 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 acros

Re: [PATCH v3] Introduce attribute reverse_alias

2023-07-17 Thread 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-implemente

[PATCH v4] Introduce attribute sym

2023-07-19 Thread 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 (alia

Re: [PATCH v4] Introduce attribute sym

2023-07-21 Thread 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 d

Re: [PATCH] aarch64: testsuite: symbol-range compile only

2022-07-05 Thread Alexandre Oliva via Gcc-patches
On Jun 30, 2022, Hans-Peter Nilsson wrote: > On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote: >> +proc check_effective_target_two_plus_gigs { } { >> +return [check_no_compiler_messages two_plus_gigs executable { >> +int dummy[0x8000]; > Don'

Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp

2022-07-05 Thread Alexandre Oliva via Gcc-patches
On Jun 27, 2022, Alexandre Oliva wrote: > On Jun 23, 2022, Jonathan Wakely wrote: >> The attached makes this a bit more efficient, and makes more of the >> code common to the mkstemp and non-mkstmp branches. I'll wait to hear >> back from you before pushing it (since it has Joel's name on the >>

Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails

2022-07-05 Thread Alexandre Oliva via Gcc-patches
On Jun 30, 2022, Sebastian Huber wrote: > From my point of view this is behaviour is an RTEMS bug. Instead of > adding tweaks for RTEMS, it would be better to report the issues and > fix them in RTEMS. It could be also a Newlib issue. Thanks, I've just filed https://devel.rtems.org/ticket/4674

Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp

2022-07-05 Thread Alexandre Oliva via Gcc-patches
On Jul 5, 2022, Jonathan Wakely wrote: > The cast itself is fine, but I'd like a comment like "N.B. pid_t is a > pointer on vxworks" so I don't "simplify" it again. libstdc++: testsuite: why cast getpid result Add a comment next to the getpid call to explain why the typecast is needed. Regst

[PATCH] Introduce hardbool attribute for C

2022-07-07 Thread Alexandre Oliva via Gcc-patches
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

[PATCH] Control flow redundancy hardening

2022-07-07 Thread Alexandre Oliva via Gcc-patches
This patch introduces an optional hardening pass to catch unexpected execution flows. Functions are transformed so that basic blocks set a bit in an automatic array, and (non-exceptional) function exit edges check that the bits in the array represent an expected execution path in the CFG. Funct

Re: [PATCH] Introduce hardbool attribute for C

2022-07-08 Thread Alexandre Oliva via Gcc-patches
On Jul 8, 2022, Richard Biener wrote: > The documentation should probably be explicit about this case. Please consider, for purposes of review, the following incremental patchlet as if integrated with yesterday's submission. diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index a63a9415

Re: [PATCH] Introduce hardbool attribute for C

2022-07-08 Thread Alexandre Oliva via Gcc-patches
On Jul 8, 2022, Richard Biener wrote: > Does this follow some other compilers / language? It is analogous to Ada's booleans with representation clauses and runtime validation checking at use points. > Is such feature used in existing code? Not that I know. The attribute name was my choice.

Re: [PATCH] Control flow redundancy hardening

2022-07-08 Thread Alexandre Oliva via Gcc-patches
On Jul 8, 2022, Richard Biener wrote: > I'm possibly missing the importance of 'redundancy' in -fharden-control-flow I took "Control Flow Redundancy" as a term of the art and never questioned it. I think the "redundancy" has to do with the fact that control flow is generally affected by tests

[PATCH] i386 testsuite: cope with --enable-default-pie

2022-07-11 Thread Alexandre Oliva via Gcc-patches
Running the testsuite on a toolchain build with --enable-default-pie had some unexpected fails. Adjust the tests to tolerate the effects of this configuration option on x86_64-linux-gnu and i686-linux-gnu. The cet-sjlj* tests get offsets before the base symbol name with PIC or PIE. A single pa

Re: [PATCH] i386 testsuite: cope with --enable-default-pie

2022-07-12 Thread Alexandre Oliva via Gcc-patches
On Jul 11, 2022, Mike Stump wrote: > Ok. >> PS: There's at least one additional FAIL with --enable-default-pie in >> the trunk, namely gcc.target/i386/mvc7.c >> WDYT? > Seems reasonable. Thanks, here's what I installed. i386 testsuite: cope with --enable-default-pie Running the testsuite o

[PATCH] i386 PIE: accept @GOTOFF in load/store multi base address

2022-07-26 Thread Alexandre Oliva via Gcc-patches
Looking at the code generated for sse2-{load,store}-multi.c with PIE, I realized we could use UNSPEC_GOTOFF as a base address, and that this would enable the test to use the vector insns expected by the tests even with PIC, so I extended the base + offset logic used by the SSE2 multi-load/store p

[PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

2022-07-26 Thread Alexandre Oliva via Gcc-patches
g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed, have made it clear that there were problems in the optimizations to use @GOTOFF to refer to locally-bound ifuncs. GNU ld as recently as May 2018 would reject such constructs, whereas later versions will silently accept but gener

Re: [PATCH] i386 testsuite: cope with --enable-default-pie

2022-07-26 Thread Alexandre Oliva via Gcc-patches
On Jul 11, 2022, Mike Stump wrote: > On Jul 11, 2022, at 6:47 PM, Alexandre Oliva wrote: >> >> Running the testsuite on a toolchain build with --enable-default-pie >> had some unexpected fails. >> Regstrapped on x86_64-linux-gnu, and also tested on i686-linux-gnu, with >> and without --enable-

Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

2022-07-28 Thread Alexandre Oliva via Gcc-patches
On Jul 27, 2022, "H.J. Lu" wrote: > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva wrote: >> The use of @GOTOFF for locally-bound but externally-visible symbols >> (e.g. protected visibility) also breaks pointer identity if the >> canonical address ends up preempted by a PLT entry. > Here is

[PATCH v2 00/10] Introduce strub: machine-independent stack scrubbing

2022-07-28 Thread Alexandre Oliva via Gcc-patches
This patch adds the strub attribute for function and variable types, command-line options, passes and adjustments to implement it, documentation, and tests. Stack scrubbing is implemented in a machine-independent way: functions with strub enabled are modified so that they take an extra stack wat

[PATCH v2 01/10] Introduce strub: documentation, and new command-line options

2022-07-28 Thread Alexandre Oliva via Gcc-patches
Ada already has some strub documentation in gcc/ada/doc/gnat_rm/security_hardening_features.rst. for gcc/ChangeLog * common.opt (fstrub=*): New options. * doc/extend.texi (strub): New type attribute. (__builtin_stack_address): New function. (Stack Scrubbing): Ne

[PATCH v2 02/10] Introduce strub: torture tests for C and C++

2022-07-28 Thread Alexandre Oliva via Gcc-patches
for gcc/testsuite/ChangeLog * c-c++-common/torture/strub-callable1.c: New. * c-c++-common/torture/strub-callable2.c: New. * c-c++-common/torture/strub-const1.c: New. * c-c++-common/torture/strub-const2.c: New. * c-c++-common/torture/strub-const3.c: New.

[PATCH v2 03/10] Introduce strub: non-torture tests for C and C++

2022-07-28 Thread Alexandre Oliva via Gcc-patches
for gcc/testsuite/ChangeLog * c-c++-common/strub-O0.c: New. * c-c++-common/strub-O1.c: New. * c-c++-common/strub-O2.c: New. * c-c++-common/strub-O2fni.c: New. * c-c++-common/strub-O3.c: New. * c-c++-common/strub-O3fni.c: New. * c-c++-commo

[PATCH v2 04/10] Introduce strub: tests for C++ and Ada

2022-07-28 Thread Alexandre Oliva via Gcc-patches
for gcc/testsuite/ChangeLog * g++.dg/strub-run1.C: New. * g++.dg/torture/strub-init1.C: New. * g++.dg/torture/strub-init2.C: New. * g++.dg/torture/strub-init3.C: New. * gnat.dg/strub_attr.adb, gnat.dg/strub_attr.ads: New. * gnat.dg/strub_ind.adb,

[PATCH v2 05/10] Introduce strub: builtins and runtime

2022-07-28 Thread Alexandre Oliva via Gcc-patches
for gcc/ChangeLog * builtins.def (BUILT_IN_STACK_ADDRESS): New. (BUILT_IN___STRUB_ENTER): New. (BUILT_IN___STRUB_UPDATE): New. (BUILT_IN___STRUB_LEAVE): New. * builtins.cc: Include ipa-strub.h. (STACK_STOPS, STACK_UNSIGNED): Define. (expan

[PATCH v2 06/10] Introduce strub: attributes

2022-07-28 Thread Alexandre Oliva via Gcc-patches
Ada already has support for the strub attributes stubbed-out, and the front-end code already has support for them and their effects in the type system. for gcc/ChangeLog * attribs.cc: Include ipa-strub.h. (decl_attributes): Support applying attributes to function type,

[PATCH v2 07/10] Introduce strub: infrastructure interfaces and adjustments

2022-07-28 Thread Alexandre Oliva via Gcc-patches
Introduce the new strub passes, adjust other passes and front-end declaration for strub. for gcc/ChangeLog * Makefile.in (OBJS): Add ipa-strub.o. * ipa-inline.cc: Include ipa-strub.h. (can_inline_edge_p): Test strub_inlinable_to_p. * ipa-split.cc: Include ipa-st

[PATCH v2 08/10] Introduce strub: strub modes

2022-07-28 Thread Alexandre Oliva via Gcc-patches
This initial fragment of ipa-strub.cc covers strub modes and their internal representation. for gcc/ChangeLog * ipa-strub.cc: New. diff --git a/gcc/ipa-strub.cc b/gcc/ipa-strub.cc new file mode 100644 index 0..d61b7e2e36e43 --- /dev/null +++ b/gcc/ipa-strub.cc @@ -0,0 +1,3

[PATCH v2 09/10] Introduce strub: strubm (mode assignment) pass

2022-07-28 Thread Alexandre Oliva via Gcc-patches
This middle fragment of ipa-strub.cc covers strub mode selection and assignment logic, and most of the pass that performs that assignment. +/* Return TRUE iff NODE calls builtin va_start. */ + +static bool +calls_builtin_va_start_p (cgraph_node *node) +{ + bool result = false; + + for (cgraph

[PATCH v2 10/10] Introduce strub: strub pass

2022-07-28 Thread Alexandre Oliva via Gcc-patches
This final fragment of ipa-strub.cc adds the strub pass, that implements the needed function interface changes and adds calls to the strub builtins. +/* Define a pass to introduce strub transformations. */ +const pass_data pass_data_ipa_strub = { + SIMPLE_IPA_PASS, + "strub", + OPTGROUP_NONE

Re: [PATCH v2 00/10] Introduce strub: machine-independent stack scrubbing

2022-07-28 Thread Alexandre Oliva via Gcc-patches
On Jul 29, 2022, Alexandre Oliva wrote: > This patch adds the strub attribute for function and variable types, > command-line options, passes and adjustments to implement it, > documentation, and tests. The entire patch, and the patchlets used for testing, are available from the GCC git repo, br

Re: [PATCH] configure: respect --with-build-time-tools [PR43301]

2022-08-01 Thread Alexandre Oliva via Gcc-patches
Hello, Eric, Thanks for looking into this. On Aug 1, 2022, Eric Gallager via Gcc-patches wrote: >> This just reassigns the value that was retrieved a couple of lines >> above from the very same variable. > Oh, ok, so I guess this isn't necessary after all? Yeah, I don't see how this patch co

Re: [PATCH] configure: respect --with-build-time-tools [PR43301]

2022-08-02 Thread Alexandre Oliva via Gcc-patches
On Aug 2, 2022, Eric Gallager wrote: > On Tue, Aug 2, 2022 at 1:24 AM Alexandre Oliva wrote: >> -elif test -x as$build_exeext; then >> +elif test -x as$build_exeext \ >> + && { test "x$build_exeext" != "x" \ >> +|| test "x`grep '^# Invoke as, ld or nm from the build tree' \ >

Re: [PATCH] configure: respect --with-build-time-tools [PR43301]

2022-08-04 Thread Alexandre Oliva via Gcc-patches
On Aug 3, 2022, Eric Gallager wrote: > OK, after reviewing the surrounding code, I think it makes sense; do > you want to commit it, or should I? Please proceed, if you have the cycles to give it a round of meaningful testing (as in, including reconfigure with configure-generated as, and also w

Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

2022-08-08 Thread Alexandre Oliva via Gcc-patches
On Aug 1, 2022, "H.J. Lu" wrote: > On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote: >> > You may also need to do something like this bit for mvc10.c on ia32 PIE. >> > Because the ifunc is called through an alias, AFAICT we don't even >> > notice that the call target is (an alias to) an ifunc. G

Re: [PATCH v2 02/10] Introduce strub: torture tests for C and C++

2022-08-09 Thread Alexandre Oliva via Gcc-patches
Ping? https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599011.html Here's an incremental patch for some of these tests, that avoids some relatively rare spurious failures. diff --git a/gcc/testsuite/c-c++-common/torture/strub-run1.c b/gcc/testsuite/c-c++-common/torture/strub-run1.c index b24

Re: [PATCH] Introduce hardbool attribute for C

2022-08-09 Thread Alexandre Oliva via Gcc-patches
Ping? (sorry, Joseph, I failed to Cc: you last time) https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598034.html https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598084.html On Jul 7, 2022, Alexandre Oliva wrote: > for gcc/c-family/ChangeLog > * c-attribs.cc (c_common_attribute_

Re: [PATCH] i386 PIE: accept @GOTOFF in load/store multi base address

2022-08-09 Thread Alexandre Oliva via Gcc-patches
Ping? https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598872.html On Jul 27, 2022, Alexandre Oliva wrote: > for gcc/ChangeLog > * config/i386/i386.cc (symbolic_base_address_p, > base_address_p): New, factored out from... > (extract_base_offset_in_addr): ... here and exte

Re: [PATCH] i386 testsuite: cope with --enable-default-pie

2022-08-09 Thread Alexandre Oliva via Gcc-patches
Ping? https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598276.html On Jul 27, 2022, Alexandre Oliva wrote: > for gcc/testsuite/ChangeLog > * g++.dg/abi/anon1.C: Disable pie on ia32. > * g++.dg/abi/anon4.C: Likewise. > * g++.dg/cpp0x/initlist-const1.C: Likewise. > *

Re: [PATCH] i386 testsuite: cope with --enable-default-pie

2022-08-09 Thread Alexandre Oliva via Gcc-patches
On Aug 9, 2022, Alexandre Oliva wrote: > Ping? > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598276.html Oops, sorry, I linked to the wrong patch. This is the one I meant to ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598874.html > On Jul 27, 2022, Alexandre Oliva wrot

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

2023-08-03 Thread 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 regar

Re: [PATCH v4] Introduce attribute sym

2023-08-15 Thread 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? Ma

Re: [PATCH] Introduce hardbool attribute for C

2023-06-16 Thread 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, absen

Re: [PATCH] Introduce hardbool attribute for C

2023-06-21 Thread 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 the

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

2023-06-21 Thread 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 diffic

Re: [PATCH] Introduce hardbool attribute for C

2023-06-21 Thread 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 co

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

2023-06-22 Thread 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 Disi

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

2023-06-22 Thread 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 linke

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

2023-06-23 Thread 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

Re: [PATCH] Introduce hardbool attribute for C

2023-06-23 Thread 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 b

Re: [PATCH] Introduce hardbool attribute for C

2023-06-23 Thread 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

Re: [PATCH] Introduce hardbool attribute for C

2023-06-23 Thread 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 Qi

Re: [PATCH] Introduce hardbool attribute for C

2023-06-28 Thread 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

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

2023-06-28 Thread 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

[testsuite] tolerate enabled but missing language frontends

2023-06-28 Thread 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.

Re: [PATCH] Introduce hardbool attribute for C

2023-06-29 Thread 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 witho

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
On Apr 5, 2022, Alexandre Oliva wrote: > Would something like this be acceptable/desirable? It's overreaching, > in that not all arm platforms are expected to fail, but the result on > them will be an unexpected pass, which is not quite as bad as the > unexpected fail we get on most arm variant

[arm] [testsuite] asm-flag-4.c: match quotes in expected message

2023-02-16 Thread Alexandre Oliva via Gcc-patches
Quotes were added around the "asm" keyword in the message expected by the test, so the test needs adjusting. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? for gcc/testsuite/ChangeLog * gcc.target/arm/asm-flag-4.c: Match quotes a

[libstdc++] [testsuite] intro/names.cc: undef func on vxw7krn

2023-02-16 Thread Alexandre Oliva via Gcc-patches
The '#define func' added in 2021, to test that system headers don't violate the user namespace, exposes such a bug in the vxworks sysLib.h header, so add yet another such annotated workaround. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?

[PATCH] [arm] xfail fp-uint64-convert-double-* on all arm targets

2023-02-16 Thread Alexandre Oliva via Gcc-patches
It wasn't long ago that I xfailed these tests on arm-*-eabi, but the fail is expected on all other arm targets: even when hard float is available, conversions between 64-bit integers and double are always emulated on ARM, and the emulation disregards rounding modes. So, bump the xfail to all of

[libstdc++] Use __gthread_join in jthread/95989

2023-02-16 Thread Alexandre Oliva via Gcc-patches
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570617.html Bernd Edlinger reported that the 95989.cc test fails without pthread_join at the end of main, but pthread_join is no good for a test that doesn't require pthreads. This patch adds a __gthread_join call instead. Regstrapped on

[PR100127] Test for coroutine header in clang-compatible tests

2023-02-16 Thread Alexandre Oliva via Gcc-patches
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. Regstrapped on x86_64-

[PATCH] Skip module_cmi_p and related unsupported module test

2023-02-16 Thread Alexandre Oliva via Gcc-patches
When a multi-source module is found to be unsupported, we fail module_cmi_p and subsequent sources. Override proc unsupported to mark the result in module_do, and test it to skip module_cmp_p and subsequent related tests. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-

[PATCH] Drop need for constant I in ctf test

2023-02-16 Thread Alexandre Oliva via Gcc-patches
Though I is supposed to be a constant expression, this is not the case on vxworks, but this is not what this debug information format test is testing for, so use real constants to initialize complex variables. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).

[PATCH] Accept pmf-vbit-in-delta extra warning

2023-02-16 Thread Alexandre Oliva via Gcc-patches
cp_build_binary_op, that issues -Waddress warnings, issues an extra warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect when comparing a pointer-to-member-function literal with null. The reason for the extra warning is that, on arm targets, TARGET_PTRMEMFUNC_VBIT_LOCATION == pt

[PATCH] [vxworks] make wint_t and wchar_t the same distinct type

2023-02-16 Thread Alexandre Oliva via Gcc-patches
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and wchar_t mapped to the same underlying type, but this caused a glitch in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to wchar_t, headers got included in the test that declared functions that take wint_t parameters, and

[PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

2023-02-16 Thread Alexandre Oliva via Gcc-patches
The expected asm output for aes-fuse-[12].c does not correspond to that which is generated when -mfix-cortex-a57-aes-1742098 is enabled. It was introduced after the test, and enabled by default for the selected processor. Disabling the option restores the circumstance that was tested for. Regst

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
check_dangling_stores has some weirdnesses that causes its behavior to change when the target ABI requires C++ ctors to return this: while scanning stmts backwards in e.g. the AS ctor on a target that returns this in ctors, the scan first encounters a copy of this to the SSA name used to hold the

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
Back when quotes were added around "+cdecp" in the "coproc must be a constant immediate" error in arm-builtins.cc, tests for that message lagged behind. Fixed thusly. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? for gcc/testsuite/Chang

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
The test uses arm_hard_ok and arm_softfp_ok as if they were mutually exclusive, but they test whether the corresponding -mfloat-abi= flag is usable, not whether it is in effect, so it is possible for both to pass, and then the test comes out with incorrect expectations whichever the default float

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
Commit 3a7ba8fd0cda387809e4902328af2473662b6a4a, a patch for tree-ssa-sink, enabled the removal of basic blocks in ways that affected the generated code for both of these tests, deviating from the expectations of the tests. The simplest case is that of -2, in which the edge unsplitting ends up e

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
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. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to instal

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

2023-02-16 Thread Alexandre Oliva via Gcc-patches
The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only tests for compile-time support. Add a requirement for mve hardware. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? for gcc/testsuite/ChangeLog PR target/104882

[PATCH] [libstdc++] xfail noreplace tests on vxworks

2023-02-16 Thread Alexandre Oliva via Gcc-patches
vxworks ignores O_EXCL in open, so noreplace open succeeds when it is expected to fail. xfail the tests. Regstrapped on x86_64-linux-gnu. Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? for libstdc++-v3/ChangeLog * testsuite/27_io/basic_ofstream/open/char/norepl

[PATCH] [arm] [vxworks] xfail fp-double-convert-float-1.c

2023-02-16 Thread Alexandre Oliva via Gcc-patches
Even with vcvt.f32.f64, the FE_UPWARD test rounds down and fails. I'm not sure whether this opcode disregards the rounding mode (it looks like it should take it into account) or it is a qemu bug, but it does not look like GCC is doing anything wrong, and the test fails, so I'm marking the fail a

[PATCH] [libstdc++] ensure mutex_pool survives _Safe_sequence_base

2023-02-16 Thread Alexandre Oliva via Gcc-patches
On vxworks, after destroying the semaphore used to implement a mutex, __gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls __throw_concurrence_lock_error. Nothing ensures the mutex_pool mutexes survive init-once objects containing _Safe_sequence_base. If such an object completes constr

[PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

2023-02-16 Thread Alexandre Oliva via Gcc-patches
On platforms that fail the ptrtomemfn-cast-to-pfn hack, such as arm-*-vxworks*, time_get fails with %I and %p because the state is not preserved across do_get calls. This patch introduces an alternate hack, that encodes the state in unused bits of struct tm before calling do_get, extracts them i

Re: [PATCH] [libstdc++] ensure mutex_pool survives _Safe_sequence_base

2023-02-17 Thread Alexandre Oliva via Gcc-patches
On Feb 17, 2023, Alexandre Oliva wrote: > On vxworks, after destroying the semaphore used to implement a mutex, > __gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls > __throw_concurrence_lock_error. Nothing ensures the mutex_pool > mutexes survive init-once objects containing _Safe_se

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

2023-02-17 Thread Alexandre Oliva via Gcc-patches
Hi, richi, On Feb 17, 2023, Richard Biener wrote: > It seems the case should run into Yeah, but when the stmt is _7 = this_2(D), lhs is _7, whereas lhs_ref.ref is this_2(D), a parm decl's default def, so def_stmt is a gimple_nop, and this is not a decl_by_reference, so we don't skip stores.add,

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

2023-02-17 Thread Alexandre Oliva via Gcc-patches
On Feb 17, 2023, Alexandre Oliva wrote: > Now, really, I did not get as far as trying to make sense of the > algorithm in there (get_ref definitely doesn't do what its name suggests > to me), I just saw a bunch of weirdnesses in blackbox testing and > failing variations, that seemed to suggest so

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

2023-02-22 Thread Alexandre Oliva via Gcc-patches
Hello, Christophe, On Feb 20, 2023, Christophe Lyon wrote: > On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote: >> >> Back when quotes were added around "+cdecp" in the "coproc must be >> a constant immediate" error in arm-builtins.cc, tests

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

2023-02-22 Thread Alexandre Oliva via Gcc-patches
On Feb 17, 2023, Jakub Jelinek wrote: > My worry is that people often invoke the time_get APIs on uninitialized > struct tm. Yeah. I thought you meant get(), but it looks like you meant do_get() as well. I seem to have overread the permissions to overwrite tm members, to update its current con

Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type

2023-02-22 Thread Alexandre Oliva via Gcc-patches
Hello, Jason, On Feb 17, 2023, Jason Merrill wrote: > On 2/17/23 23:04, Alexandre Oliva wrote: >> >> We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and >> wchar_t mapped to the same underlying type, but this caused a glitch >> in Wstringop-overflow-6.C: on vxworks, wint_t is typ

Re: [PATCH] Accept pmf-vbit-in-delta extra warning

2023-02-22 Thread Alexandre Oliva via Gcc-patches
On Feb 17, 2023, Jason Merrill wrote: > On 2/17/23 23:02, Alexandre Oliva wrote: >> >> cp_build_binary_op, that issues -Waddress warnings, issues an extra >> warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect >> when comparing a pointer-to-member-function literal with null. >>

Re: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

2023-02-22 Thread Alexandre Oliva via Gcc-patches
Hello, Kyrylo, On Feb 20, 2023, Kyrylo Tkachov wrote: > So rather than overriding this awkward part with > -mno-fix-cortex-a57-aes-1742098 I'd rather just select a different > CPU that enables that fusion and isn't afflicted by this workaround, > such as -mcpu=cortex-a53. Sounds good to me. >

Re: [PATCH] Skip module_cmi_p and related unsupported module test

2023-02-22 Thread Alexandre Oliva via Gcc-patches
On Feb 20, 2023, Jason Merrill wrote: > This seems like an ugly kludge around that problem, but I don't have > any clever ideas of a better approach short of rewriting everything. > So, OK with a comment explaining the rationale above your overridden > "unsupported". > Also, your commit subject

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

2023-02-22 Thread Alexandre Oliva via Gcc-patches
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? [PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods From: Alexandre Oliva

  1   2   3   4   5   >