On Apr 10, 2025, at 6:38 AM, Christophe Lyon wrote:
>
> On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
>>
>>> From: Christophe Lyon
>>> Date: Thu, 10 Apr 2025 15:21:23 +0200
>>
>> Not sure why I'm CC:ed on this one, not being a maintainer
>> of the testsuite or targets where gcov tes
On Mar 27, 2025, at 12:29 PM, Jakub Jelinek wrote:
>
> On Thu, Mar 27, 2025 at 12:05:21AM +, Sam James wrote:
>> The test was being ignored because dg.exp looks for .C in g++.dg/.
>>
>> gcc/testsuite/ChangeLog:
>> PR middle-end/112938
>>
>> * g++.dg/strub-internal-pr112938.cc: Mov
On Mar 26, 2025, at 11:34 AM, David Malcolm wrote:
>
> This patch kit:
> * adds minimal Python bindings for libgdiagnostics.so (below contrib)
> * implements a new dg-lint tool (below contrib) to detect for
>common mistakes in our testsuite, using Python 3 (and the above
>bindings)
> *
On Mar 20, 2025, at 8:11 AM, Alex Coplan wrote:
> On 09/02/2024 15:32, Alex Coplan wrote:
>> On 04/05/2022 09:59, Martin Liška wrote:
>>> Supports change in libsanitizer where it newly reports:
>>> READ of size 4 at 0xc3d4 tags: 02/01(00) (ptr/mem) in thread T0
>>>
>>> So the 'tags' conta
On Feb 13, 2025, at 1:51 AM, Alexandre Oliva wrote:
>
> Some vect-simd-clone tests fail when targeting ancient x86 variants,
> because the expected transformations only take place with -msse4 or
> higher.
>
> So arrange for these tests to take an -msse4 option on x86, so that
> the expected vect
On Jan 19, 2025, at 12:47 PM, Torbjorn SVENSSON
wrote:
>
> On 2025-01-19 21:20, Andrew Pinski wrote:
>> On Sun, Jan 19, 2025 at 12:17 PM Torbjörn SVENSSON
>> wrote:
>>>
>>> Ok for trunk?
>>>
>>> --
>>>
>>> Most baremetal toolchains will not have an implementation for alarm and
>>> sigaction
On Jan 16, 2025, at 11:46 AM, Alexandre Oliva wrote:
>
> Since the machine-independent widening multiply logic was improved
> PR113560, ARM's wmul-[567].c fail. AFAICT the logic takes advantage
> of the fact that, after zero-extending a narrow integral type to a
> wider type, further zero- or si
On Jan 16, 2025, at 11:43 AM, Alexandre Oliva wrote:
>
> The regexp that matches options that mess with multilibs matches
> -mfloat=abi=, but that's probably a typo for -mfloat-abi=. Fix that,
> and add -msoft-float and -mhard-float.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-eabi
On Jan 16, 2025, at 11:42 AM, Alexandre Oliva wrote:
>
> Tests that include need to be skipped when libstdc++ is built
> in freestanding mode.
Ok.
> for gcc/testsuite/ChangeLog
>
> PR rtl-optimization/113994
> * g++.dg/pr113994.C: Require hosted libstdc++.
On Jan 16, 2025, at 11:39 AM, Alexandre Oliva wrote:
>
> A few more dfp tests that recently got backported to gcc-14 override
> dfp.exp's selection of default action depending on dfprt. Let the
> default stand.
>
> This is a followup of the patch I've just pinged. Regstrapped on
> x86_64-linux
On Jan 9, 2025, at 10:25 PM, Alexandre Oliva wrote:
>
> dfp.exp sets the default to compile when dfprt is not available, but
> some dfp bitint tests override the default without that requirement,
> and try to run even when dfprt is not available.
>
> Instead of overriding the default, rewrite th
On Jan 6, 2025, at 3:05 PM, Alexandre Oliva wrote:
>
> On Dec 22, 2024, Alexandre Oliva wrote:
>
>> for gcc/testsuite/ChangeLog
>
>> PR testsuite/118025
>> * gcc.dg/field-merge-1.c: Convert constants to desired types.
>> * gcc.dg/field-merge-3.c: Likewise.
>> * gcc.dg/fiel
On Jan 2, 2025, at 4:00 PM, Sam James wrote:
>
> This testcase came up in a recent LLVM bug report [0] for DSE vs
> -ftrivial-auto-var-init=. Add it to our testsuite given that area
> could do with better coverage.
>
> [0] https://github.com/llvm/llvm-project/issues/119646
>
> gcc/testsuite/Cha
On Dec 2, 2024, at 4:27 AM, Maciej W. Rozycki wrote:
>
> These tests can take several seconds per compilation to complete, taking
> total elapsed time measured in minutes. Mark them as expensive so as to
> let people skip them where they want to save on testing time.
>
> gcc/testsuite/
On Dec 3, 2024, at 3:08 AM, Georg-Johann Lay wrote:
>
> This patch fixes some unrelated tests that were failing.
> In most cases, bad tests are slipping in because they
> are preprocessed like:
>
> size_t -> long unsigned int -> breaks when size_t is smaller etc.
>
> Other reason is that they a
On Nov 26, 2024, at 11:55 AM, David Malcolm wrote:
>
> Ping
Ok. I'll punt on the diff documentation bits.
> On Mon, 2024-11-18 at 16:22 -0500, David Malcolm wrote:
>> Another ping for this patch; any pex experts out there?
>>
>> Thanks!
>> Dave
>>
>> On Wed, 2024-05-29 at 17:06 -0400, David M
On Nov 26, 2024, at 11:56 AM, David Malcolm wrote:
>
> Ping for this patch; thanks!
Ok.
> On Fri, 2024-11-15 at 20:05 -0500, David Malcolm wrote:
>> In r12-6650-g5c69acb32329d4 we updated our sources from .c to .cc
>> since for some time GCC has been implemented in C++, not C.
>>
>> GCC plugin
On Nov 21, 2024, at 7:49 AM, Carl Love wrote:
>
> Ping 6
>
> On 11/14/24 1:36 PM, Carl Love wrote:
>> Ping 5
>>
>> On 11/5/24 8:27 AM, Carl Love wrote:
>>> Ping 4
>>>
>>> On 10/28/24 4:28 PM, Carl Love wrote:
Ping 3
On 10/17/24 1:31 PM, Carl Love wrote:
> Ping 2
>
On Nov 18, 2024, at 1:25 PM, David Malcolm wrote:
>
> Ping for this testsuite patch; I've occasionally found it *very*
> helpful when debugging DejaGnu.
Ok. Do put a comment that this is for debugging so no one removes it.
On Oct 29, 2024, at 4:15 PM, Alexandre Oliva wrote:
>
> Multiple tests fail on ia32 with -fPIE enabled by default because of
> different call sequences required by the call-saved PIC register
> (no-callee-saved-*.c), uses of the constant pool instead of computing
> constants (pr100865-*.c), and u
On Oct 29, 2024, at 4:08 PM, Alexandre Oliva wrote:
>
> When we select a non-bx get_pc_thunk, we get an extra mov to set up
> the PIC register before the abort call. Expect that mov or a
> get_pc_thunk.bx call.
>
> Regstrapped on x86_64-linux-gnu; also tested on i686-linux-gnu with
> -fPIE. Ok
On Oct 31, 2024, at 1:56 PM, Sam James wrote:
>
> Sam James writes:
>
>> Andrew pointed this out when committing those testsuite fixes earlier. We
>> may as well make these proper torture tests rather than having them
>> unnecessarily in the special lto/ dir which is meant for multiple files
>>
On Oct 25, 2024, at 12:47 PM, Sam James wrote:
>
> PR107467 ended up being fixed by the fix for PR115110, but let's
> add the testcase on top.
>
> gcc/testsuite/ChangeLog:
> PR tree-optimization/107467
> PR middle-end/115110
>
> * g++.dg/lto/pr107467_0.C: New test.
> ---
> OK?
On Oct 4, 2024, at 9:40 AM, Georg-Johann Lay wrote:
>
> Some of the float64 and float32x test cases are using double built-ins
> and hence require double64plus resp. double_float32xplus, i.e. double
> is at least as good as float32x.
>
> This patch adds according dg-require-effective-target filt
On Sep 26, 2024, at 11:47 AM, Alex Coplan wrote:
>
> In r15-3585-g9759f6299d9633cabac540e5c893341c708093ac I added a test which
> started failing on PowerPC. The test checks that we unroll exactly one loop
> three times with the following:
>
> // { dg-final { scan-ltrans-rtl-dump-times "Unrolle
On Sep 16, 2024, at 2:23 AM, Jonathan Wakely wrote:
>
> Arsen mentioned that he has some similar emacs config for formatting
> libstdc++ code which should probably be added to the repo somewhere (I
> don't know enough about emacs to know where that should be, or how to
> make it only apply to the
On Sep 12, 2024, at 6:08 PM, Alexandre Oliva wrote:
>
> On Sep 12, 2024, Mike Stump wrote:
>
>> On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote:
>>>
>>> Here's an updated and refreshed version that gets trunk built with
>>> --disable-host
On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote:
>
> Here's an updated and refreshed version that gets trunk built with
> --disable-hosted-libstdcxx on x86_64-linux-gnu to not get any spurious
> fails during in-tree testing. Also bootstrapped on hosted
> x86_64-linux-gnu. Ok to install?
Ok.
Ok. Though, some of these files are so littered with target bits that
essentially it doesn't make too much a difference.
On Jul 18, 2024, at 4:44 AM, Thomas Schwinge wrote:
>
> OK to push (once testing completes) the attached
> "Make 'target-supports.exp' additions for nvptx target generally a
On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote:
>
> On Nov 9, 2023, Mike Stump wrote:
>
>> On Nov 8, 2023, at 8:29 AM, Alexandre Oliva wrote:
>>>
>>> On Nov 5, 2023, Mike Stump wrote:
>>>
>>>> that, otherwise, I'll approve th
On Sep 2, 2024, at 4:23 PM, Andi Kleen wrote:
>
> Andi Kleen writes:
>
> PING^3
Ok.
>> Andi Kleen writes:
>>
>> PING^2 for https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>>
>> This fixes some musttail related test suite failures that cause noise on
>> various targets.
>>
On Aug 18, 2024, at 3:28 PM, Hans-Peter Nilsson wrote:
>
> As noticed when verifying the dejagnu fix. Tested cris-elf
> with a new newlib that arranges to emit the mentioned
> warning, with/without the update in dejagnu to handle the
> miniscule "in". Ok to commit?
Ok.
On Jun 11, 2024, at 10:56 PM, Alexandre Oliva wrote:
>
> On Jun 11, 2024, Andrew Pinski wrote:
>
>> I think we should just fully revert the changes to
>> dg-additional-sources and add an explicit `dg-do run` to pr95401.cc
>
> I don't suppose an explicit "dg-do run" would make things work relia
On Aug 29, 2024, at 9:07 AM, Alex Coplan wrote:
>
> Since r15-3254-g3f51f0dc88ec21c1ec79df694200f10ef85915f4
> added scan-ltrans-rtl* variants to scanltranstree.exp, it no longer
> makes sense to have "tree" in the name. This renames the file
> accordingly and updates users.
>
> Tested on aarch
On Jun 4, 2024, at 11:30 AM, Thomas Schwinge wrote:
>
> For my recent work on
> "nvptx target: Global constructor, destructor support, via nvptx-tools 'ld'",
> I needed more variants of C/C++ test cases for 'constructor',
> 'destructor' function attributes with priority: in particular, split into
On May 23, 2024, at 6:28 AM, Alexandre Oliva wrote;
> I came up with an entirely different approach:
>
>
> g++.dg/vect/pr95401.cc has dg-additional-sources, and that fails when
> check_vect_support_and_set_flags finds vector support lacking for
> execution tests: tests decay to compile tests, an
On Apr 26, 2024, at 11:17 AM, Abe Skolnik wrote:
You never need to do any work in .po files, omit that part and repost.
On Apr 22, 2024, at 2:56 AM, Alexandre Oliva wrote:
>
> This patch takes feedback received for 3 earlier patches, and adopts a
> simpler approach to skip the still-failing tests, that I believe to be
> in line with ppc maintainers' expressed preferences.
> https://gcc.gnu.org/pipermail/gcc-patche
On Apr 18, 2024, at 4:32 AM, Alexandre Oliva wrote:
>
> On Apr 16, 2024, Alexandre Oliva wrote:
>
>> * gcc.dg/builtin-dynamic-object-size-1.c: Likewise.
>> * gcc.dg/builtin-dynamic-object-size-2.c: Likewise.
>> * gcc.dg/builtin-dynamic-object-size-3.c: Likewise.
>> * gcc.dg/
On Apr 15, 2024, at 8:50 PM, Alexandre Oliva wrote:
>
> Complete r13-2205, adjusting an arm-specific test that expects a
> no-longer-issued error at an empty initializer.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86- and x86_64-vxworks7r2. Ok to install
On Apr 15, 2024, at 8:20 PM, Alexandre Oliva wrote:
>
> The test expected the address of a literal string, converted to long
> long, to yield a positive value. That expectation doesn't necessarily
> hold, and the test fails where it doesn't.
>
> Adjust the test to use a pointer that will compar
On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
Ok.
> As the tests assume that strndup() is visible (only part of
> POSIX.1-2008) define the guard to ensure that it's visible. Currently,
> glibc appears to always have this defined in C++, newlib does not.
>
> Without
On Feb 15, 2024, at 6:08 AM, Jonathan Yong <10wa...@gmail.com> wrote:
>
> Attached patch OK?
Ok.
> Copy/pasted for review convenience.
>
> diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c
> b/gcc/testsuite/c-c++-common/Wrestrict.c
> index 4d005a618b3..57a3f67e21e 100644
> --- a/gcc/testsuit
On Feb 26, 2024, at 7:56 AM, Alejandro Colomar wrote:
>
> I don't see an obvious order in that file. Where would you put the
> option?
The best place, would be to put it just after:
-Warray-bounds
-Warray-bounds=n
This is a functional style grouping that best mirrors the existing orde
On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote:
>
> Warn about the following:
>
>char s[3] = "foo";
No ObjC specific impact here, so no need for ObjC review.
As a member of the peanut gallery, I like the patch.
Joseph, this is been submitted 5 times over the past year. Any thoughts
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>
> There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
> target. I think claiming for it that it is a lra target is strange (even
> though it effectively returns true for targetm.lra_p ()), unsure if it
> supports asm goto
On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote:
>
> Given the recent discussions on IRC started with Andrew P. mentioning that
> an asm goto outputs test should have { target lra } and the lra effective
> target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
> we clearly ha
On Feb 12, 2024, at 11:38 AM, Edwin Lu wrote:
>
> There is currently no support for matching at least x lines of assembly
> (only scan-assembler-times). This patch would allow setting upper or lower
> bounds.
>
> Use case: using different scheduler descriptions and/or cost models will
> change
On Feb 15, 2024, at 9:03 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk?
Ok.
> gcc/testsuite/ChangeLog:
> PR113278
> * c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE.
> * c-c++-common/analyzer/flex-with-call-summaries.c: Same.
> * c-c++-common/analyzer/flex-witho
> On Feb 12, 2024, at 5:27 AM, Rainer Orth
> wrote:
>
> The following patches have remained unreviewed for a week or more:
>
> testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706]
>https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644842.html
Jason commented.
On Feb 10, 2024, at 10:07 AM, FX Coudert wrote:
>
> The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is
> partly because symbols are prefixed with underscore, and also because the
> order of operands in the addition is reversed (but I think it’s valid still).
> The code
On Feb 10, 2024, at 7:21 AM, Torbjörn SVENSSON
wrote:
>
> I have confirmed that this updated pr97969.c file still hangs with
> gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.
>
> Ok for trunk?
Ok.
On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON
wrote:
>
> Changes since v1:
> - Replaced .* with [^\r\n]* to avoid matching newline.
>
> Ok for trunk and releases/gcc-13?
Ok.
On Feb 6, 2024, at 8:58 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk and releases/gcc-13?
Ok. If .* goes across newlines, you might want to not use ..
> -if {![regexp -- "/${compiler}(\\.exe)? -quiet.*$compiler_pattern"
> $gcc_output]} {
> +if {![regexp -- "/${compiler}(\\.exe)? .*-
On Jan 24, 2024, at 1:01 AM, Rainer Orth wrote:
>
> gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its
> introduction in
>
> commit 43201f2c2173894bf7c423cad6da1c21567e06c0
> Author: Roger Sayle
> Date: Mon May 30 21:20:09 2022 +0100
>
>PR target/70321: Split double word equ
On Jan 24, 2024, at 1:12 AM, Rainer Orth wrote:
>
> gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86
> since its introduction in
>
> commit 4814b63c3c2326cb5d7baa63882da60ac011bd97
> Author: Roger Sayle
> Date: Mon Jul 10 09:04:29 2023 +0100
>
>i386: Add AVX512 suppo
On Jan 30, 2024, at 2:30 AM, Iain Sandoe wrote:
>
> tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If asan people want to chime in...
On Jan 30, 2024, at 2:31 AM, Iain Sandoe wrote:
>
> tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If the ubsan people want to review this, certainly, happy to have them
chime in.
On Jan 28, 2024, at 7:03 AM, Iain Sandoe wrote:
>
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?
Ok. If you discover needed updates, please feel free to drop them in.
On Jan 12, 2024, at 2:52 AM, Hans-Peter Nilsson wrote:
>
> Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)
>
> On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:
>
>> Tested mmix-knuth-mmixware (where all torture-variants of
>> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
>
On Dec 21, 2023, at 8:49 AM, Christophe Lyon wrote:
>
> While investigating possible race conditions in the GCC testsuites
> caused by bufferization issues, I wanted to investigate workarounds
> similar to GDB's READ1 [1], and I noticed it was not always possible
> to override EXPECT when running
On Dec 11, 2023, at 12:29 AM, FX Coudert wrote:
>
> The test is currently failing on x86_64-apple-darwin. This patch requires
> nonpic, as suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297
> by Andrew Pinski.
>
> OK to commit?
Ok.
On Nov 6, 2023, at 2:59 AM, Marc Poulhiès wrote:
>
> These 3 tests fails parsing the 'vect' dump when not using -mavx. Make
> the dependency explicit.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/vect-ifcvt-18.c: Add dep on avx_runtime.
> * gcc.dg/vect/vect-simd-clone-16f.c: Likew
On Nov 6, 2023, at 3:01 AM, Marc Poulhiès wrote:
>
> Contrary to glibc, including stdio.h from newlib defines mode_t which
> conflicts with the test's type definition.
>
> .../gcc/testsuite/gcc.dg/analyzer/fd-4.c:19:3: error: redefinition of typedef
> 'mode_t' with different type
> ...
> .../in
On Nov 6, 2023, at 2:57 AM, Marc Poulhiès wrote:
>
> Using newlib produces a different codegen because the support for c99
> differs (see libc_has_function hook).
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr106910-1.c: Disable for newlib.
> ---
> Tested on x86_64-linux and x86_64
On Nov 24, 2023, at 7:15 PM, Hans-Peter Nilsson wrote:
>
> While looking at the various targets, I found that the m32r
> target has two options implemented as opposites:
> -mbranch-cost=1 and -mbranch-cost=2, that have a bug that
> makes them yield their functionally opposite effect;
> i.e. -mbra
On Nov 19, 2023, at 6:34 PM, Alexandre Oliva wrote:
>
> Having extended check_and_warn_address_or_pointer_of_packed_member to
> find the packed (short) enum pointer in the cast expression coming
> from the C++ front-end, and amended the C++ front end to mark short
> enums as TYPE_PACKED, C++ issu
On Nov 8, 2023, at 5:49 PM, Alexandre Oliva wrote:
>
> LTS GNU/Linux distros from 2018, still in use, don't have
> pthread_cond_clockwait. There's no trivial way to detect it so as to
> make the test conditional, but there's an easy enough way to silence
> the fail due to lack of the function in
On Nov 8, 2023, at 8:29 AM, Alexandre Oliva wrote:
>
> On Nov 5, 2023, Mike Stump wrote:
>
>> that, otherwise, I'll approve this version.
>
> FWIW, this version is not usable as is. Something went wrong in my
> testing, and several regressions only visib
On Nov 8, 2023, at 7:55 AM, Alexandre Oliva wrote:
>
> gcc.target/i386/pr95126-m32-[34].c expect push instructions that are
> only present with -mno-accumulate-outgoing-args, so make that option
> explicit rather than dependent on tuning.
>
> Regstrapped on x86_64-linux-gnu, also tested with gcc
On Nov 5, 2023, at 12:33 PM, FX Coudert wrote:
>
> kind ping for this easy patch
>
>
>> Le 30 oct. 2023 à 15:19, FX Coudert a écrit :
>>
>> Hi,
>>
>> The test is currently failing on x86_64-apple-darwin with "decimal
>> floating-point not supported for this target”.
>> Marking the test as r
On Oct 19, 2023, at 8:16 PM, Alexandre Oliva wrote:
>
> On Mar 10, 2021, Alexandre Oliva wrote:
>
>> ppc configurations that have -mstrict-align enabled by default fail
>> gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
>> MEM_REFs, which defeats the tested-for strlen opt
On Oct 2, 2023, at 1:24 AM, Christophe Lyon wrote:
>
> ping?
>
> On Sun, 10 Sept 2023 at 21:31, Christophe Lyon
> wrote:
> Some targets like arm-eabi with newlib and default settings rely on
> __sync_synchronize() to ensure synchronization. Newlib does not
> implement it by default, to make u
On Nov 1, 2023, at 6:11 PM, Alexandre Oliva wrote:
>
> Several C++ tests fail with --disable-hosted-libstdcxx, whether
> because stdc++ext gets linked in despite not being built, because
> standard headers are included but that are unavailable in this mode,
> or because headers are (mistakenly?)
On Oct 27, 2023, at 8:11 AM, Christophe Lyon wrote:
>
> In some configurations of our validation setup, we always call the
> compiler with -Wl,-rpath=XXX, which instructs the driver to invoke the
> linker if none of -c, -S or -E is used.
>
> This happens to be the case in the PCH tests, where dg
On Oct 26, 2023, at 5:34 AM, Richard Sandiford
wrote:
> dg-pch.exp handled dg-require-effective-target pch_supported_debug
> as a special case, by grepping the source code. This patch tries
> to generalise it to other dg-require-effective-targets, and to
> dg-skip-if.
>
> There also seemed to b
On Jun 22, 2023, at 10:35 PM, Alexandre Oliva wrote:
>
> 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 w
On Jun 20, 2023, at 10:21 AM, David Malcolm wrote:
> Does this testsuite patch look OK?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html
>
> Thanks
> David
>
> On Mon, 2023-06-12 at 19:11 -0400, David Malcolm wrote:
>> Please can someone review this testsuite patch:
>> http
On Jun 12, 2023, at 1:35 AM, Bernhard Reutner-Fischer
wrote:
>
> On Sat, 10 Jun 2023 11:29:36 -0700
> Mike Stump wrote:
>
>> On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer
>> wrote:
>
>>>But well. Either way, wh
On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer
wrote:
>
> On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches
> wrote:
>> simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd
>> say do it in python at the bottom as it would
On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> about 10 minutes to run for cris-elf in the "gdb simulator"
I'd let the libstdc++ people comment on specific things. I'll comment on
general things. We could
On Jun 7, 2023, at 8:01 AM, Thomas Schwinge wrote:
> On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
> wrote:
>> The attached changes [...]
>
> ... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
> "Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++
On Jun 7, 2023, at 7:54 AM, Thomas Schwinge wrote:
>
> On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches
> wrote:
>> Attached is a simple middle end implementation of detection of
>> mismatched pairs of calls to C++ new and delete, along with
>> a substantially enhanced implementation o
On Jun 7, 2023, at 1:12 AM, Alexandre Oliva wrote:
>
> Several tests are timing out when targeting x86-*-vxworks with qemu.
>
> Bump their timeout factor.
Ok. I think these are obvious to people that have to work with simulators and
the testsuite so if you want to self approve you can.
LLM, machine learning and AI likes coding with data types that are weird,
float16, bf16, 8 bit float and 4 bit floats. Longer term, would be nice to
natively support these everywhere. Would be nice to trial run them in the
compiler, sort it all out, so that the implementation experience can driv
On Mar 30, 2023, at 6:51 AM, Alexandre Oliva wrote:
>
> 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 tes
On Feb 27, 2023, at 2:29 AM, Jonathan Yong via Gcc-patches
wrote:
>
> Attached patch OK?
Ok.
>* c-c++-common/Warray-bounds.c: Fix excess warnings on
>
> LLP64.<0001-c-c-common-Warray-bounds.c-fix-excess-warnings-on-LL.patch>
On Mar 25, 2023, at 1:33 AM, Alexandre Oliva wrote:
>
> 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
On Mar 20, 2023, at 3:06 PM, David Malcolm via Gcc-patches
wrote:
>
> c-c++-common/diagnostic-format-sarif-file-4.c is a test case for
> quoting non-ASCII source code in a SARIF diagnostic log.
>
> The SARIF standard mandates that .sarif files are UTF-8 encoded.
>
> PR testsuite/105959 notes t
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
On Mar 6, 2023, at 10:52 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to apply?
Ok.
> * lib/target-supports.exp (check_compile): Support scanning tree-dumps.
On Mar 6, 2023, at 10:45 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to commit?
Ok.
> -- >8 --
> The RTL "expand" dump is the first RTL dump, and it also appears to be
> the earliest trace of the target having implemented sibcalls.
> Including the "," in the pattern searched for, to t
Ok
On Mar 3, 2023, at 5:58 PM, Hans-Peter Nilsson wrote:
>
> Ping...
>
>> From: Hans-Peter Nilsson
>> Date: Fri, 24 Feb 2023 20:16:03 +0100
>>
>> Ok to commit?
On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches
wrote:
>
> Some trivial test case fixes. Ok for trunk?
Ok.
On Feb 27, 2023, at 5:54 PM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ping...
Ok.
>
>> From: Hans-Peter Nilsson
>> Date: Thu, 16 Feb 2023 21:05:29 +0100
>
>> Asking for the lines outside the "#if __CRIS__" part.
>> Ok to commit?
>>
>> -- >8 --
>> tm.texi says for BIGGEST_ALIGNMENT (fr
On Feb 27, 2023, at 9:59 AM, Hans-Peter Nilsson wrote:
>
>> From: Mike Stump
>> Date: Mon, 27 Feb 2023 09:41:18 -0800
>
>>> diff --git a/gcc/testsuite/lib/multiline.exp
>>> b/gcc/testsuite/lib/multiline.exp
>>> index 84ba9216642e..5eccf2bbebc1 100
On Feb 22, 2023, at 12:04 PM, Alexandre Oliva wrote:
>
> 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-vxworks
On Feb 24, 2023, at 9:54 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to commit?
Ok. Thanks.
> diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp
> index 84ba9216642e..5eccf2bbebc1 100644
> --- a/gcc/testsuite/lib/multiline.exp
> +++ b/gcc/testsuite/lib/mul
On Feb 16, 2023, at 10:59 PM, Alexandre Oliva wrote:
>
> 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
On Feb 16, 2023, at 10:20 PM, Alexandre Oliva wrote:
>
> 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 emul
1 - 100 of 2403 matches
Mail list logo
