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
On Feb 16, 2023, at 10:15 PM, Alexandre Oliva wrote:
>
> 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?
Ok.
On Dec 20, 2022, at 1:22 AM, Jonathan Yong via Gcc-patches
wrote:
>
> This fixes the following:
>
> Excess errors:
>
> gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:12: warning: overflow in
> conversion from 'long long unsigned int' to 'long int' changes value from
> '4611686018427387903'
On May 10, 2022, at 6:31 PM, Kito Cheng via Gcc-patches
wrote:
>
> LGTM, that's only added a new option for RISC-V and won't affect all
> other targets, so I assume I can approve that.
Yes. Usual and customary for ports.
Ok.
> On Aug 24, 2022, at 4:59 AM, herron.phi...@googlemail.com wrote:
>
> From: Philip Herron
>
> This copy's over code from other front-end testsuites to enable testing
> for the rust front-end specifically.
>
> Co-authored-by: Marc Poulhiès
> Co-authored-by: Thomas Schwinge
> ---
> gcc/te
On Aug 10, 2022, at 11:56 AM, Philip Herron wrote:
>
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end in more patches.
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-default-pie on both platforms. Ok to instal
Ok.
On May 5, 2022, at 2:35 AM, Marc Poulhies via Gcc-patches
wrote:
>
> Marc Poulhiès writes:
>
>> Require effective target fpic for newly added test.
>>
>> gcc/testsuite/
>> * g++.dg/ext/visibility/visibility-local-extern1.C: Add missing
>> dg-require-effective-target fpic.
>>
>
On Apr 4, 2022, at 4:52 AM, Robin Dapp via Gcc-patches
wrote:
> OK for trunk?
> +/* Since r12-4475-g247c407c83f001 the following immediates are being
> + converted and directly stored in the literal pool so no explicit
> + conversion is necessary. */
Not fan of git revision numbers in the
On Jan 28, 2022, at 5:49 AM, chenglulu wrote:
>
> gcc/testsuite/
>
>* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
>* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
>* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
>* gcc.dg/20020312-
On Jan 29, 2022, at 8:26 AM, Jakub Jelinek via Gcc-patches
wrote:
>
> This test fails everywhere, because ? doesn't match literal ?.
> It should use \\? instead. I've also changed those .s in there.
> Tested on x86_64-linux (-m32/-m64) and powerpc64le-linux, ok for trunk?
Ok.
On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches
wrote:
>
> Nitpicking time. It's spelled "ones' complement" rather than "one's
> complement". I didn't go into config/.
>
> Ok for trunk?
So, is it two's complement or twos' complement then? Seems like it should be
the same, but w
On Aug 19, 2021, at 1:02 PM, Iain Sandoe wrote:
>
> Although the cctools assembler is based of GNU GAS, it is from a
> very old version (1.38) which does not support many of the features
> that the target supports test is expecting***.
>
> tested on i686 and x86_64 darwin versions using the ccto
On Jul 27, 2021, at 10:30 AM, Martin Sebor via Gcc-patches
wrote:
> On 7/27/21 9:16 AM, Jonathan Wakely via Gcc-patches wrote:
>> Secondly, releases are not issued by the GNU Project at all, they're
>> issued by the GCC release managers.
>
> I (and I suspect most users unfamiliar with the inner
On May 18, 2021, at 9:02 AM, Thomas Schwinge wrote:
> Is the attached "Add '__OPTIMIZE__' DejaGnu selector" OK to push after
> testing?
Ok.
This isn't a patch to gcc, please stop posting non-technical content to this
list. Please review what this list is for and the rules for this list before
you post again, thanks.
> On May 14, 2021, at 7:47 AM, abebeos via Gcc-patches
> wrote:
>
> Hi there IT-fascists, clowns, master-clowns,
>
On Apr 27, 2021, at 8:32 AM, Alexandre Oliva wrote:
>
> The test is supposed to check that the abstract lexical block of a
> function that was inlined doesn't have attributes, and that the
> concrete inlined lexical block does.
> The problem is that '[.../...]+ +[^(].*' matches '/ (DIE...', bec
On Feb 24, 2021, at 1:10 AM, Alexandre Oliva wrote:
>
> On Feb 23, 2021, Jim Wilson wrote:
>> If we add default multilibs for you
>
> *nod*, it's a very familiar issue to me, I know where that's coming
> from, no worries.
So, what I'd do is if you have a triplet component that isn't used much,
On Feb 18, 2021, at 6:15 AM, Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Feb 17, 2021 at 01:46:37PM -0500, Nathan Sidwell wrote:
>> I'd missed that macros were allocated from GC storage, and that they can
>> become unattached from an identifier, and therefore not GC-reachable.
>>
On Jan 15, 2021, at 1:13 AM, Tamar Christina via Gcc-patches
wrote:
> I ran sed script late over the tests which accidentally
> introduced a syntax error in the tests.
>
> This fixes it.
>
> Committed under the obvious rule.
>
> Ok for master?
:-)
Which is it? Anyway, Ok.
On Jan 1, 2021, at 6:41 PM, Alexandre Oliva wrote:
>
> On Jan 1, 2021, Mike Stump wrote:
>
>> On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote:
>>>
>>> On Dec 29, 2020, Mike Stump wrote:
>>>
>>>> a[i-1] = i;
>>>
On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote:
>
> On Dec 29, 2020, Mike Stump wrote:
>
>> a[i-1] = i;
>
> 'fraid that won't pass:
>
>for (int i = 0; i < n; i++) {
>assert (a[i] == i);
>}
Ok, how about your version with the comment updated?
On Dec 22, 2020, at 1:47 PM, Alexandre Oliva wrote:
>
> The tests use -mfp16-format=alternative, and so should not be run
> if that option isn't supported.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote:
>
> This test fails during the execution on VxWorks 7 when using
> C++-14 and C++-17.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
On Dec 22, 2020, at 1:57 PM, Alexandre Oliva wrote:
>
> The only TLS model supported in VxWorks kernel mode is local-exec.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
On Dec 22, 2020, at 1:56 PM, Alexandre Oliva wrote:
>
> This change adds -mno-long-calls to the list of compiler options
> to make sure we generate short call code, allowing the assembly
> matching to pass.
>
> This is added unconditionally to the dg-options (as opposed to using
> dg-additional-
1 - 100 of 2378 matches
Mail list logo