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, what
>>> should we do about remote env,
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 100644
>>> --- a/gcc/testsuite/lib/multiline.exp
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
> ---
>
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;
>>>
>>> 'fraid that won't pass:
>>>
>>> for (int i = 0; i < n; 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.
On Dec 22, 2020, at 1:14 PM, Alexandre Oliva wrote:
>
> In kernel mode, an application must include vxWorks.h before any other
> system header, this patch adds exactly that to the test that were
> failing due to a missing declaration that was found in vxWorks.h.
I'm inclined to rather have a
On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches
wrote:
>
> This patch fixes a handful of tests with non-unique names which confuse
> the living hell out of compare_tests, particularly if one of two tests
> [x]fail while the other is [x]pass which compare_tests will flag as a
> regression
On Nov 3, 2020, at 1:12 PM, Nathan Sidwell wrote:
>
> Here is the implementation of C++20 modules that I have been developing on
> the devel/c++-modules branch over the last few years.
I was just recently wondering about this. Congratulations.
> It is some 25K new lines of code (plus
On Oct 14, 2020, at 6:46 AM, Tom de Vries wrote:
>
> OK for trunk?
Ok.
On Sep 24, 2020, at 2:38 AM, Tom de Vries wrote:
>
> Fix this by adding an effective target ident_directive, and requiring
> it in both test-cases.
> OK for trunk?
Ok.
On Aug 12, 2020, at 6:57 AM, Tom de Vries wrote:
>
> The nvptx target currently doesn't support effective target sync_int_long,
> although it has support for 32-bit and 64-bit atomic.
>
> When enabling sync_int_long for nvptx, we run into a failure in
> gcc.dg/pr86314.c:
> ...
> nvptx-run:
On Aug 10, 2020, at 2:30 PM, Marek Polacek via Gcc-patches
wrote:
>
> Thanks a lot. Here's the latest version of my patch, which only adds dg-ice
> at this point.
>
> So, um, OK?
Ok.
On Aug 7, 2020, at 6:16 AM, Nathan Sidwell wrote:
>
> On 8/6/20 8:01 PM, Mike Stump wrote:
>> On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote:
>>>
XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error)
PASS: g++.dg/foo.C -std=c++17 (test for excess errors)
Which one of
On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote:
>
>> XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error)
>> PASS: g++.dg/foo.C -std=c++17 (test for excess errors)
>> Which one of these would you not like to see?
>
> Neither of these is solving the issue. How do I find the ICES that
On Aug 6, 2020, at 5:23 AM, Tom de Vries wrote:
>
> There currently is no sync_char_short-enabled run test that tests
> __sync_val_compare_and_swap.
>
> OK for trunk?
Ok.
On Aug 4, 2020, at 5:54 PM, Marek Polacek wrote:
>> As you find it difficult to express a test using the existing mechanisms,
>> let's talk about those and see if anyone has a good idea on how to express
>> it. I think ICEs are the most annoying to manage, but, I think excess and
>> prune
On Aug 5, 2020, at 5:56 AM, Marek Polacek wrote:
>
> Sorry for being unclear. Say you have
>
> // PR c++/55408
>
> struct foo {
>template
>void bar();
> };
>
> template
> void foo::bar() {}
>
> int main()
> {
>extern int i;
>foo {}.bar<>();
> }
>
> which we wrongly accept.
On Aug 4, 2020, at 3:16 PM, Marek Polacek via Gcc-patches
wrote:
>
> The benefit of dg-accepts-invalid was that you would
> get an XPASS even for a test that should not be accepted, but you didn't know
> what line to expect an error on, so you put a dg-error at the end of the test.
I think for
On Aug 4, 2020, at 3:08 PM, Marek Polacek via Gcc-patches
wrote:
>
> That works well if you know where to expect an error. But if you don't, it's
> worse. E.g.,
>
> // { dg-xfail-if "" { *-*-* } }
> int i = nothere; // demonstrates something that errors out
> // { dg-error "" } didn't know
I think the read of the room is that people think it would be generally useful,
so let approve the general plan.
So, now we are down to the fine details. Please do see just how far you can
stretch the existing mechanisms to cover what you need to do. I think the
existing mechanisms should be
I'll punt to the the C++ front-end folks to chime in. Usually we only check in
bugs that are fixed, as they are fixed, this is what makes it a regression
suite. Doing this does have advantages, like, the testsuite is small and
doesn't have duplicates and doesn't test anything that is known to
On Jul 18, 2020, at 8:19 PM, Hans-Peter Nilsson wrote:
>
> Long-standing FAIL remedied; committed. Maybe better to list
> the targets that *do* support arbitrary frame access?
Yes, it would be better if test cases that fall way to low in portability are
listed instead against what platforms
On Jul 9, 2020, at 2:56 AM, Tamar Christina wrote:
> This adds verbose output to dg-set-compiler-env-var and dg-set-target-env-var
> so you can actually see what they're setting when you add -v -v.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
Ok.
On Jun 2, 2020, at 10:37 PM, Frederik Harwath wrote:
>
> Frederik Harwath writes:
>
> ping :-)
Ok.
>> Frederik Harwath writes:
>>
>> Hi Rainer, hi Mike,
>> ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545803.html
>>
>> Best regards,
>> Frederik
>>
>>> Hi Thomas,
>>>
>>>
On Jun 11, 2020, at 7:28 AM, Martin Jambor wrote:
>
> On Tue, Jun 09 2020, Mike Stump wrote:
>> I think I'd prefer the fix on the other side, if reasonable. I'd give
>> them some time to see about a fix there before selecting this patch.
>
> given Alexandre's email, are you OK with the patch?
I think I'd prefer the fix on the other side, if reasonable. I'd give them
some time to see about a fix there before selecting this patch.
On Jun 9, 2020, at 5:42 AM, Martin Jambor wrote:
> On Tue, Jun 09 2020, Thomas Schwinge wrote:
>> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>>>
On Apr 27, 2020, at 12:43 PM, Christophe Lyon via Gcc-patches
wrote:
> It seems it's not possible to write these tests so that they works in
> all combinations of toolchain configuration and options used for testing :-(
So, generally, you can have each change in configuration reflected in a
On Mar 26, 2020, at 3:00 PM, Maciej W. Rozycki wrote:
>
> I have actually considered extracting the bits already, but I hesitated
> putting that forward that as having looked at the part that we require I
> have thought it to be very messy:
Yeah, sometimes it's like that. I glanced at the
On Mar 17, 2020, at 2:52 PM, Maciej W. Rozycki wrote:
>
> On Fri, 28 Feb 2020, H.J. Lu wrote:
>>
>> Libffi 3.4 ABI was changed to support CET. But it isn't the first
>> time ABI change for libffi,
>
> Have we made any conclusions WRT the way to move forward with this stuff?
> Things remain
83 matches
Mail list logo
