Re: [PATCH v4] Introduce attribute sym

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?

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

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

Re: [PATCH v4] Introduce attribute sym

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

[PATCH v4] Introduce attribute sym

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

Re: [PATCH v3] Introduce attribute reverse_alias

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

[PATCH v3] Introduce attribute reverse_alias

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

Re: [PATCH] Introduce hardbool attribute for C

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

[testsuite] tolerate enabled but missing language frontends

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 v3] Introduce strub: machine-independent stack scrubbing

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

Re: [PATCH] Introduce hardbool attribute for C

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] Introduce hardbool attribute for C

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

Re: [PATCH] Introduce hardbool attribute for C

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

Re: [PATCH] Introduce hardbool attribute for C

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

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

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

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

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

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

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

Re: [PATCH] Introduce hardbool attribute for C

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

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

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

Re: [PATCH] Introduce hardbool attribute for C

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

Re: [PATCH] Introduce hardbool attribute for C

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,

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

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,

Re: [PATCH] Introduce hardbool attribute for C

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,

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

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 *

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

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 *

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

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

Re: [PATCH] fix frange_nextafter odr violation

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

[PATCH] fix frange_nextafter odr violation

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

[testsuite] bump some tsvc timeouts

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:

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

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,

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

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

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

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

[PATCH] [libstdc++] [testsuite] xfail double-prec from_chars for x86_64 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 x86_64-*-vxworks*. Tested on x86_64-vxworks7r2 with gcc-12. Ok to install? for libstdc++-v3/ChangeLog

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

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

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

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

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

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

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

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 } >> } } */ >>

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

--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

[PATCH] [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. Bootstrapped on x86_64-linux-gnu. Also tested on ppc- and

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

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 *

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

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

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

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

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

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

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

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 > *

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

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 *

[PATCH] [testsuite] require profiling for -pg

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. *

[PATCH] [testsuite] require pthread for openmp

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 |

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

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 |

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

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.

[PATCH] Check for sysconf decl on vxworks

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

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

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

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

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

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

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

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

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

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

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

harden-conditionals: detach values before compares

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.

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

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

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

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 >

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

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

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

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

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

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?

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

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

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

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,

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

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 *

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

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.

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

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

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

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

Re: [PATCH] Introduce -nolibstdc++ option

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

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

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

Re: [PATCH] Introduce -nolibstdc++ option

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

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

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

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

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

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

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] [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. Regstrapped on ppc64-linux-gnu. Also tested with

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

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

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

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?

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

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

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

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

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

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

[PATCH] [testsuite] fix array element count

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

[PATCH] [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

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

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

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

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)); &

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

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

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

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

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

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 >

[PATCH] [rs6000] adjust return_pc debug attrs

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

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

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

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

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

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

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. >> *

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

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?

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

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,

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

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

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

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 -

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

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 :-)

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

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

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

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++

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

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 } } >>> >>>

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

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,

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

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

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

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

  1   2   3   4   5   >