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.
>
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.
>> *
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
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
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.
>
>
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
> ---
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
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
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
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
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.
> *
> 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
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
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
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:
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
> ...
>
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
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.
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++
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
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 vis
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
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
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
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
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
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
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
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:
>>
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 b
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
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
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
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
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
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
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
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
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
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
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
> +++
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
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
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
>
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
> ---
>
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
> ---
>
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
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
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.
>*
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
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
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...',
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
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
>
On Dec 22, 2020, at 1:45 PM, Alexandre Oliva wrote:
>
> The conflicting definition of OK is present in VxWorks RTP headers too.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
Ok to stylize all the #undef in the same way. This is one happens
On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote:
>
> In VxWorks 7, UINT32 is defined in both modes, kernel and rtp. Adjust
> the work around accordingly.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote:
>
> The constexpr iteration dereferenced an array element past the end of
> the array.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
How about:
a[i-1] = i;
instead? This I think better
On Dec 22, 2020, at 1:43 PM, Alexandre Oliva wrote:
>
> Linking in vxworks kernel-mode is partial linking, so missing symbols
> are not detected.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
Generally nicer to bunch all like ones ("partial
On Dec 22, 2020, at 1:42 PM, Alexandre Oliva wrote:
>
> These are no longer applicable.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
On Dec 22, 2020, at 1:41 PM, Alexandre Oliva wrote:
>
> VxWorks headers define ERROR as a macro, which conflicts with the use
> in the test.
>
> 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:
>
> The vxworks kernel-mode linking is partial linking, so it cannot
> detect missing symbols.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
On Dec 22, 2020, at 1:37 PM, Alexandre Oliva wrote:
>
> Adjust vxworks initpri expectations, given that vxworks7 has switched
> to .init_array.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
I suppose I should say that if the port maintainers
On Dec 22, 2020, at 1:36 PM, Alexandre Oliva wrote:
>
> This test currently fails on VxWorks 7 SR06x0 targets when in kernel
> mode, because it expects a discrepancy between built-in and system
> intmax_t for all VxWorks targets when in kernel mode. Fortunately,
> this has now been fixed when
On Dec 22, 2020, at 1:34 PM, Alexandre Oliva wrote:
> Match xfail on kernel instead of rtp mode.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
Longer term, would be nice to fix includes the relevant file to have the
relevant definition.
1 - 100 of 3043 matches
Mail list logo
