Re: gcc.dg/intmax_t-1.c compiles without error on VxWorks 7 SR06x0

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

Re: Fix VxWorks xfail filters on pthread-init-?.c

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.

Re: Add conditional include of vxWorks.h for kernel mode

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

Re: [committed] Fix non-unique testnames

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

Re: [00/32] C++ 20 Modules

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

Re: [PATCH][testsuite] Don't overwrite compiler_flags in check_compile

On Oct 14, 2020, at 6:46 AM, Tom de Vries wrote: > > OK for trunk? Ok.

Re: [PATCH][testsuite] Add effective target ident_directive

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.

Re: [PATCH][testsuite, nvptx] Add effective target sync_int_long_stack

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:

Re: RFC: Monitoring old PRs, new dg directives [v2]

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.

Re: RFC: Monitoring old PRs, new dg directives

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=

Re: RFC: Monitoring old PRs, new dg directives

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

Re: [PATCH][testsuite] Add gcc.dg/ia64-sync-5.c

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.

Re: RFC: Monitoring old PRs, new dg directives

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

Re: RFC: Monitoring old PRs, new dg directives

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.

Re: RFC: Monitoring old PRs, new dg directives

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

Re: RFC: Monitoring old PRs, new dg directives

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

Re: RFC: Monitoring old PRs, new dg directives

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

Re: RFC: Monitoring old PRs, new dg directives

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

Re: gcc.dg/Wno-frame-address.c: Skip for cris and mmix.

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

Re: [PATCH 4/6] Testsuite: Make it easier to debug environment setting functions

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.

Re: PING Re: testsuite: clarify scan-dump file globbing behavior

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

Re: WWDC thread: support for darwin/macOS going forward

On Jun 22, 2020, at 3:51 PM, Eric Gallager wrote: > > Hi, at Apple's WWDC this year they have announced that they are doing > yet another architecture transition, so I was wondering what exactly > would be the best way to go about adding support for it? I usually use emacs and git to add ports

Re: BRIG FE testsuite: Fix all dump-scans (Was: Re: drop -aux{dir,base}, revamp -dump{dir,base})

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

Re: BRIG FE testsuite: Fix all dump-scans (Was: Re: drop -aux{dir,base}, revamp -dump{dir,base})

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

Re: dejagnu version update?

On May 14, 2020, at 11:11 AM, Tom Tromey wrote: > >> "Rob" == Rob Savoye writes: > > Rob> Not that team, the folks I talked to thought I was crazy for wanting > Rob> to refactor it. :-) > > I don't think refactoring dejagnu is crazy, but I think it's pretty hard > to imagine rewriting

back to cvs, cool

As seen in recent bug report: CVS Commits 2020-05-12 20:40:40 UTC I guess that git thing was a bust and we're back to using cvs now. At least Ian did up the remote patches to make cvs work better.

dejagnu version update?

I've changed the subject to match the 2015, 2017 and 2018 email threads. On May 13, 2020, at 3:26 AM, Thomas Schwinge wrote: > > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old" > vs. "new") that ought to return identical results, I found that they > didn't: > I have

Re: [PATCH 1/8] testsuite: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok and arm_v8_2a_i8mm_ok_nocache

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

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

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

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

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

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

On Feb 14, 2020, at 1:26 PM, Segher Boessenkool wrote: > It remains to be seen how much of it can be used by other targets. > Pretending something is generic while it in fact is just a mass of > special cases isn't useful, it's just costly. Oh, yeah, of course. Ours was designed in two pieces,

Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot

On Feb 14, 2020, at 11:57 AM, Maciej W. Rozycki wrote: > > Mike, Chung-Lin -- > >>> In the end I have decided to use the documented `--tool_exec' option to >>> `runtest' to contain the change within the testsuite's Makefile and its >>> `check' goal, which is inherent to the build tree and as

Re: GCC selftest improvements

On Oct 28, 2019, at 12:40 PM, Jeff Law wrote: > I'd really like to see us move to C++11 or beyond. Sadly, I don't think > we have any good mechanism for making this kind of technical decision > when there isn't consensus. I'll just point out that we do have good mechanisms in place. Consensus

Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot

On Feb 13, 2020, at 3:36 PM, Maciej W. Rozycki wrote: > > This is v2 of patch series, originally posted here: > > > >

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

On Feb 4, 2020, at 9:40 AM, Segher Boessenkool wrote: >> My intent is to make adding new built-in functions as simple as adding >> a few lines to a couple of files, and automatically generating as much >> of the initialization, overload resolution, and expansion logic as >> possible. This patch

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.

On Jan 24, 2020, at 9:45 AM, David Edelsohn wrote: > > On Fri, Jan 24, 2020 at 12:00 PM Jason Merrill wrote: >> >> On 1/24/20 8:45 AM, David Edelsohn wrote: >>> There is no ChangeLog entry for the testsuite changes. >> >> I don't believe in ChangeLog entries for testcases, but I'll add one

Re: [PATCH 1/2] analyzer: g++ testsuite support

On Feb 6, 2020, at 12:27 PM, David Malcolm wrote: > > PR analyzer/93288 reports a C++-specific ICE with -fanalyzer. > > This patch creates the beginnings of a C++ test suite for the analyzer, > so that there's a place to put test coverage for the fix. > It adds a regression test for PR

Re: [PATCH] testsuite: effective_target_march_option: support checking for -march=*

> On Jan 18, 2020, at 4:35 AM, Hans-Peter Nilsson wrote: > > testsuite: > * lib/target-supports.exp (effective_target_march_option): New. > > I see no (other) way to, depending on the absence of an option, > add an option for a specific target. Specifically, I don't see > how to do

Re: [PATCH] analyzer: ensure that all DejaGnu tests have unique names

On Jan 17, 2020, at 1:30 PM, David Malcolm wrote: > > Jeff noticed various name collisions of test names in the analyzer > testsuite, due to me using empty comment strings when using line > offsets in test directives. > > This patch adds non-empty comment strings to such DejaGnu directives >

Re: [PATCH] RFC: testsuite: add minimium version to dg-require-dot (PR analyzer/93293)

On Jan 17, 2020, at 2:07 PM, David Malcolm wrote: > > I ran into difficulties with the Graphviz format changing from under > me during an upgrade, where the new version of "dot" would reject .dot > files generated by the analyzer. > > Thoughts? [ consider this a peanut gallery comment ]

Re: [patch] allow $ in scan-tree-dump expressions matching symbol names

On Dec 20, 2019, at 8:13 AM, Olivier Hainque wrote: > > This change adjusts a few scan-tree-dump expressions > to allow '$' as well as '.' when matching symbol names, > > Ok to commit ? Ok.

Re: [patch] Prevent redefinition of WCHAR_MAX from testsuite/gcc.dg/cpp/ucs.c

On Dec 20, 2019, at 9:27 AM, Olivier Hainque wrote: > gcc/testsuite/gcc.dg/cpp/ucs.c #include > and then crafts a definition of WCHAR_MAX depending > on __WCHAR_TYPE__. > Ok to commit ? Ok.

Re: undefine OFFSET in testsuite/gcc.dg/vect/tree-vect.h

On Dec 20, 2019, at 10:11 AM, Olivier Hainque wrote: > > The attached patch is a proposal for a basic solution > to an issue which might be an improper thing done by a > system header on VxWorks, but which is a big pain to fix > at this level and very simple to address super locally. > Is this

Re: [PING][PATCH v2 2/2] testsuite: Fix run-time tracking down of `libgcc_s'

On Dec 9, 2019, at 1:30 PM, Maciej W. Rozycki wrote: > > On Fri, 29 Nov 2019, Maciej W. Rozycki wrote: > >> Fix a catastrophic libgo testsuite failure in cross-compilation where >> the shared `libgcc_s' library cannot be found by the loader at run time >> in build-tree testing and

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

On Dec 16, 2019, at 4:06 PM, Maciej W. Rozycki wrote: > > On Mon, 11 Nov 2019, Maciej W. Rozycki wrote: > >> This patch series addresses a problem with the testsuite compiler being >> set up across libatomic, libffi, libgo, libgomp with no correlation >> whatsoever to the target compiler

Re: gcc-wwwdocs branch master updated. cdc7bf90357701877546f8bac160d0fb9e20b334

On Oct 21, 2019, at 3:30 AM, Segher Boessenkool wrote: > > On Sun, Oct 20, 2019 at 06:06:30PM +0200, Gerald Pfeifer wrote: >> On Wed, 9 Oct 2019, js...@gcc.gnu.org wrote: >>> +Use "git commit" and "git push origin >>> +master" to check in the patch. >> >> I will admit I made a couple of first

Re: [Darwin, machopic 4/n, committed] Arrange to indirect IVARs when needed.

On Oct 10, 2019, at 12:25 PM, Iain Sandoe wrote: > > Objective C V2 (m64) IVAR offset refs from Apple GCC-4.x have an indirection > for m64 code on PPC (which is the only 64b user for Mach-O PIC). Apple GCC > 4.x places the indirections in the .data section, however this seems to have > been

Re: [patch, testsuite, arm] Fix ICE in gcc.dg/gimplefe-28.c

On Sep 13, 2019, at 12:06 PM, Sandra Loosemore wrote: > > For the default multilib on arm-none-eabi, gcc.dg/gimplefe-28 has been > getting an ICE because, while the target-supports infrastructure is probing > to see if it can add the command-line options to enable the sqrt insn > ("-mfpu=vfp

Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls

On Sep 11, 2019, at 1:47 PM, Jose E. Marchesi wrote: > > I am working on a new compilation mode for what I call xbpf, which is > basically eBPF plus extensions to eliminate the current restrictions to > C. The purpose of -mxbpf is mainly to test the compiler. Once the > support is in, I will

[PATCH V6 08/11] bpf: make target-supports.exp aware of eBPF

On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch makes the several effective target checks in > target-supports.exp to be aware of eBPF targets. Ok. These sort of updates will now be obvious to you, now that you have gotten your feet wet. This applies to the indirect calls

Re: [PATCH V6 05/11] bpf: new GCC port

On Sep 5, 2019, at 3:50 PM, Jose E. Marchesi wrote: > I guess I should wait for acceptance of the remaining patches not having > an explicit ack? > > This leaves the following patches that still need explicit approval: > > - [PATCH V6 03/11] testsuite: annotate c-torture/compile tests with >

Re: [PATCH V6 09/11] bpf: adjust GCC testsuite to eBPF limitations

On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch makes many tests in gcc.dg and gcc.c-torture to be skipped > in bpf-*-* targets. This is due to the many limitations imposed by > eBPF Ok. So, see my other comments about marking and automatically skipping tests in the

Re: [PATCH V6 08/11] bpf: make target-supports.exp aware of eBPF

On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch makes the several effective target checks in > target-supports.exp to be aware of eBPF targets. Ok. These sort of updates will now be obvious to you, now that you have gotten your feet wet. This applies to the indirect calls

Re: [PATCH V6 04/11] testsuite: new require effective target indirect_calls

On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch adds a new dg_require_effective_target procedure to the > testsuite infrastructure: indirect_calls. This new function tells > whether a target supports calls to non-constant call targets. Ok. I'll let people contemplate some

Re: [PATCH V6 03/11] testsuite: annotate c-torture/compile tests with dg-require-stack-size

On Aug 29, 2019, at 8:13 AM, Jose E. Marchesi wrote: > > This patch annotates tests that make use of a significant a mount of > stack space. Ok. Future changes like this are now obvious to you and you can just maintain them as you see fit.

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

On Aug 2, 2019, at 4:06 AM, Richard Biener wrote: > > IMHO voting is bike-shedding. > > Those who do the work decide. _They_ may ask questions _and_ decide whether > to listen to the answer. I'd tend to agree. I also think the recent conversion work is a fine solution, and that my

Re: wrap math.h for M_PI et al in target/i386 tests

> On Jul 30, 2019, at 5:22 AM, Uros Bizjak wrote: >> Most but not all of the tests that expect M_PI, M_PI_2 and/or M_PI_4 >> to be defined in math.h explicitly exclude one target system that does >> not satisfy this non-standard assumption. >> >> This patch introduces a wrapper header that

Re: [Darwin, testsuite] Handle Darwin's size command.

On Jul 26, 2019, at 7:52 AM, Iain Sandoe wrote: > > This one has been in my patch stack for a long time… > > Darwin's "size" command has a different header line, reflecting the Mach-O > section naming conventions. This causes tests using the command to fail > because scanasm.exp expects and

Re: [PATCH 1/3] add -Wstruct-not-pod, -Wclass-is-pod, -Wmismatched-tags (PR 61339)

On Jul 22, 2019, at 3:19 PM, Jeff Law wrote: > > On 7/8/19 3:58 PM, Martin Sebor wrote: >> The attached patch implements three new warnings: >> >> * -Wstruct-not-pod triggers for struct definitions that are not >> POD structs, >> * -Wclass-is-pod triggers for class definitions that

Re: [ARM/FDPIC v5 18/21] [ARM][testsuite] FDPIC: Enable tests on pie_enabled targets

On Jul 19, 2019, at 1:57 AM, Kyrill Tkachov wrote: > > On 5/15/19 1:39 PM, Christophe Lyon wrote: >> Some tests have the "nonpic" guard, but pass on >> arm*-*-uclinuxfdpiceabi because it is in PIE mode by default. Rather >> than adding this target to all these tests, add the "pie_enabled" >>

Re: [ARM/FDPIC v5 17/21] [ARM][testsuite] FDPIC: Handle *-*-uclinux*

On Jul 19, 2019, at 1:56 AM, Kyrill Tkachov wrote: > > On 5/15/19 1:39 PM, Christophe Lyon wrote: >> Add *-*-uclinux* to tests that work on this target. >> >> 2019-XX-XX Christophe Lyon >> >> gcc/testsuite/ >> * g++.dg/abi/forced.C: Add *-*-uclinux*. >> *

Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC

On Jul 5, 2019, at 11:28 AM, Nix wrote: > ICTF for the entire Linux kernel is about 6MiB Any reason why not add CTF to the next dwarf standard? Then, we just support the next dwarf standard. If not, have you started talks with them to add it? Long term, this is a better solution, as we then

Re: CFV: "C++ programming in GNU" interest group (possibly including coding standard development)

On May 30, 2019, at 10:55 AM, James Youngman wrote: > I'm looking into creating a C++ coding standard for GNU programs. So, parts of how we do C++ isn't really relevant to a larger community. We at times cater to a C legacy and in a pure C++ project, there may be no need to do this.

Re: [PATCH] Fix up dg-extract-results.sh

On Apr 17, 2019, at 8:59 AM, Jakub Jelinek wrote: > Ok for trunk? Ok.

Re: [Patch, Darwin] Fix PR bootstrap/89864

> On Apr 15, 2019, at 11:59 PM, Iain Sandoe wrote: > OK for trunk (after wider testing)? Didn't we make you a Darwin maintainer yet? Ok. > branches? Ok.

Re: [PATCH] Fix translation issue in config/darwin.c (PR target/80190)

On Mar 7, 2019, at 11:37 AM, Jakub Jelinek wrote: > > The following patch just makes it two complete diagnostic messages that > translators can translate as they wish. > > Ok for trunk? Ok.

Re: [Patch] [aarch64] PR target/89324 Handle stack pointer for SUBS/ADDS instructions

On Feb 21, 2019, at 4:09 PM, James Greenhalgh wrote: > >> NOTE: I have included a bunch of RTL testcases that I used in development, >> these >> don't exercise much of the compiler and are pretty specific to the backend >> as it >> currently is, so I'm not sure they give much value. I'd

Re: [PATCH] Add testcases for multiple -fsanitize=, -fno-sanitize= or -fno-sanitize-recover= options (take 2)

On Feb 14, 2019, at 6:15 AM, Jakub Jelinek wrote: > Ah, yes, UNRESOLVED doesn't show up visible when running tests by hand, > rather than doing test_summary. Here is an updated patch that adds the > needed dg-skip-if directives. Ok for trunk? Ok.

Re: [PATCH] Fix up and improve allow_blank_lines testsuite handling (PR other/69006, PR testsuite/88920)

On Feb 13, 2019, at 1:09 AM, Jakub Jelinek wrote: > > ok for trunk? Ok.

Re: [PATCH] Fix up and improve allow_blank_lines testsuite handling (PR other/69006, PR testsuite/88920, take 2)

On Feb 13, 2019, at 5:37 AM, Jakub Jelinek wrote: > Here is an updated patch that documents it. Bootstrapped/regtested on > x86_64-linux and i686-linux, ok for trunk? Ok.

Re: [PATCH] Fix up gcc.target/i386/call-1.c testcase (PR rtl-optimization/11304)

On Feb 2, 2019, at 2:32 AM, Jakub Jelinek wrote: > > Regardless of the PR87485 decision, I think we should fix this testcase. > ok for trunk? Ok. > 2019-02-02 Jakub Jelinek > > PR rtl-optimization/11304 > * gcc.target/i386/call-1.c (set_eax): Add "eax" clobber. > *

Re: [PATCH] Handle timeout warnings in dg-extract-results

On Jan 23, 2019, at 5:16 AM, Christophe Lyon wrote: > What do people think about this? Seems reasonable.

Re: [PATCH] PR60563 - FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*

On Jan 4, 2019, at 2:56 AM, Dominique d'Humières wrote: > > Is the following patch OK for trunk and the release branches? Ok. > 2019-01-04 Dominique d'Humieres > > * g++.dg/ext/sync-4.C: Add dg-xfail-run-if for darwin. > > --- ../_clean/gcc/testsuite/g++.dg/ext/sync-4.C

Re: [PATCH] restore CFString handling in attribute format (PR 88638)

On Jan 4, 2019, at 2:03 PM, Martin Sebor wrote: > > The improved handling of attribute positional arguments added > in r266195 introduced a regression on Darwin where attribute > format with the CFString archetype accepts CFString* parameter > types in positions where only char* would otherwise

Re: [PATCH] Don't run ident tests on powerpc-darwin

On Jan 2, 2019, at 5:39 AM, Rainer Orth wrote: > > It's on the brink, I'd say. The effective-keyword form is shorter and > more descriptive and can be extended to more targets way more easily. > Checking 2018-12 testresults, I find failures of the ident-*.c tests on > hppa2.0w-hp-hpux11.11 and

Re: [RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")

On Dec 31, 2018, at 9:45 PM, Joel Brobecker wrote: > > In working on updating the copyright year notices for the GDB files, > I noticed something very minor regarding the patch which added the > file below (the same file was copied in gdb's testsuite); it looks > like the year range for one of

Re: v2 [PATCH] Fixes for PR68356, PR81210, and PR81693

On Dec 29, 2018, at 5:13 AM, Dominique d'Humières wrote: > > New patch for taking into account the comments in > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01003.html > > 2018-12-29 Dominique d'Humieres > >PR tree-optimization/68356 >PR target/81210 >PR

Re: [REVISED PATCH 4/9]: C++ P0482R5 char8_t: Updates to existing core language tests

I'd like to punt to Jason for this patch. > On Dec 23, 2018, at 6:27 PM, Tom Honermann wrote: > > Attached is a revised patch that addresses changes in P0482R6 and adoption of > P0482R6 for C++20 in San Diego. Changes from the prior patch include: > - Updated a test to validate the value of

Re: [REVISED PATCH 3/9]: C++ P0482R5 char8_t: New core language tests

I'd like to punt to Jason for this patch. > On Dec 23, 2018, at 6:27 PM, Tom Honermann wrote: > > Attached is a revised patch that addresses changes in P0482R6 as well as > feedback provided by Jason for patch 2/9. Changes from the prior patch > include:

Re: [PATCH, PPC/Darwin] Fix long double symbol exports.

On Dec 6, 2018, at 11:52 AM, Iain Sandoe wrote: > > During 8.x, the rs6000 target-specific mangling was reorganised which > uncovered > a long-standing bug in Darwin’s mangling for ‘IBM’ long double. Now the > symbols > are correctly mangled, and we end up with a bunch of test link fails. >

Re: [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)

On Nov 27, 2018, at 2:18 AM, Rainer Orth wrote: > > Some assemblers, including the Solaris one, don't support UTF-8 > identifiers, which breaks the gdc.test/compilable/ddoc12.d testcase as > reported in the PR. So, another style of fix, would be to change the binding from the language

Re: FIO, powerpc-darwin mangling patch [7.x and earlier].

On Nov 27, 2018, at 7:05 AM, Iain Sandoe wrote: > > So it turns out that the Darwin PPC port was broken essentially “forever” > (before the tidy-up in 8.2) with respect to mangling the symbols for __ibm128 > type (the default long double for the port). > > In 7.x and earlier (at least back

Re: [PATCH 5/7][MSP430][TESTSUITE] Prune messages about ISO C not supporting __int20 from output of tests

On Nov 26, 2018, at 3:07 PM, Jozef Lawrynowicz wrote: > > On Mon, 26 Nov 2018 12:51:26 -0800 > Mike Stump wrote: > >> On Nov 14, 2018, at 7:56 AM, Jozef Lawrynowicz >> wrote: >>> >>> Patch 5 deals with ISO C errors emitted by tests when the l

Re: [RS6000] Don't pass -many to the assembler

On Nov 13, 2018, at 10:39 AM, Peter Bergner wrote: > > On 11/13/18 12:06 PM, Iain Sandoe wrote: >> As far as I expect, Darwin should be untouched by this - we have a separate >> assembler (which doesn’t even respond to -many), so unless there’s some >> higher level translation done (it’s not

Re: [Patch][gcc][testsuite] Skip testcases using freopen when on wrapped board

On Nov 16, 2018, at 8:16 AM, Matthew Malcomson wrote: > > On 16/11/18 16:04, Jeff Law wrote: >> On 11/15/18 12:06 PM, Martin Sebor wrote: >>> On 11/15/2018 02:39 AM, Matthew Malcomson wrote: If not we could add an { dg-require-effective-target unwrapped } directive in the

Re: [PATCH 07/10] Add dg-require-effective-target exceptions

On Nov 16, 2018, at 8:28 AM, Andrew Stubbs wrote: > > [This patch was previously approved by Richard Sandiford (with added > documentation I've still not done), but objected to by Mike Stump. I > need to figure out who's right.] Since the planned port is done and someone is

Re: [PATCH][driver] Ensure --help=params lines end with period

On Nov 20, 2018, at 3:51 AM, Tom de Vries wrote: > > this patch ensures that gcc --help=params lines end with a period by: > - fixing the help message of param HOT_BB_COUNT_FRACTION, and > - adding a test-case. > > Build and tested on x86_64. > > OK for trunk? So, normally we'd punt approval

Re: [PATCH] Fix up method-nonnull-1.mm testcase on Solaris (PR testsuite/88090)

On Nov 20, 2018, at 12:36 PM, Jakub Jelinek wrote: > > The following testcase fails on Solaris, because it doesn't print there > 'size_t', but 'std::size_t', as the type is defined by system headers and > it is not under gcc control how exactly is size_t defined. > > The following patch fixes

Re: [PATCH 10/10] Port testsuite to GCN

On Nov 26, 2018, at 12:04 PM, Mike Stump wrote: > > I'll Ok the signal one, if you prefer it over a dummy signal routine. > Though, would be nice for you to add signal if possible/reasonable. Oh, and my long term thinking on signal is that logically, it's fine to have: #if __ha

Re: [PATCH 5/7][MSP430][TESTSUITE] Prune messages about ISO C not supporting __int20 from output of tests

On Nov 14, 2018, at 7:56 AM, Jozef Lawrynowicz wrote: > > Patch 5 deals with ISO C errors emitted by tests when the large memory model > is > used. size_t and ptrdiff_t are __int20 with -mlarge, and if the test is > compiled with -pedantic-errors and -std=* or -ansi, then use of these types >

Re: [PATCH 4/7][MSP430][TESTSUITE] Fix tests when int is 16-bit by default

On Nov 14, 2018, at 7:52 AM, Jozef Lawrynowicz wrote: > > Patch 4 fixes tests when int is 16-bits by default. Ok,

Re: [PATCH 6/7][MSP430][TESTSUITE] Fix tests requiring float printf support when GCC was configured with --enable-newlib-nano-formatted-io

On Nov 14, 2018, at 7:58 AM, Jozef Lawrynowicz wrote: > > Patch 6 fixes tests expecting printf float support for targets which have been > configured with "newlib-nano-formatted-io". When newlib is configured in this > way, float printf is enabled at build time by registering _printf_float as an

Re: [PATCH 3/7][v2][MSP430][TESTSUITE] Dynamically check if size_t is large enough for tests containing large structs/arrays

On Nov 21, 2018, at 2:39 PM, Jozef Lawrynowicz wrote: > > On Wed, 14 Nov 2018 15:41:00 + > Jozef Lawrynowicz wrote: > >> Patch 3 sets up require-effective-target directives for tests which >> require the compilation of large arrays. >> Targets which have 16-bit or 20-bit size_t fail to

Re: [PATCH 3/7][MSP430][TESTSUITE] Dynamically check if size_t is large enough for tests containing large structs/arrays

On Nov 14, 2018, at 7:48 AM, Jozef Lawrynowicz wrote: > > Patch 3 sets up require-effective-target directives for tests which > require the compilation of large arrays. Ok.

Re: [PATCH 10/10] Port testsuite to GCN

On Nov 20, 2018, at 5:00 PM, Jeff Law wrote: > > On 11/16/18 9:29 AM, Andrew Stubbs wrote: >> This collection of miscellaneous patches configures the testsuite to run on >> AMD >> GCN in a standalone (i.e. not offloading) configuration. It assumes you have >> your Dejagnu set up to run

Re: [PATCH, libgcc/ARM & testsuite, ping] Optimize executable size when using softfloat fmul/dmul

On Nov 26, 2018, at 1:46 AM, Thomas Preudhomme wrote: > Ping? The testsuite parts are Ok. > On Mon, 19 Nov 2018 at 10:51, Thomas Preudhomme > wrote: >> >> FWIW, the testcases were taken from >> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01026.html

Re: [RS6000] Don't pass -many to the assembler

On Nov 12, 2018, at 3:13 PM, Alan Modra wrote: > > For people developing new code, it's the right way to go, and > especially so for people working on gcc itself. For people just > wanting stuff to compile, not so much. I fully expect a chorus of > *MORON* or worse to come from the likes of

Re: [PATCH], Remove power9 fusion support

On Nov 2, 2018, at 11:37 AM, Michael Meissner wrote: > > As I discussed in my 2018 Cauldron talk, the PowerPC GCC compiler supported a > subset of the original design for fusion in the power9 hardware using > peepholes > to fuse together ADDIS instructions and floating point load/store

Re: [PATCH, testsuite, c-compat] Handle another c/l option not recognised by older GCC or clang.

On Oct 29, 2018, at 12:53 PM, Iain Sandoe wrote: > > When using ALT_CC/CXX_UNDER_TEST in the compat/struct-layout-1 tests, the c/l > options provided to the “alt” compiler need to avoid latest and greatest GCC > capability. The patch tests to see if the ‘alt’ compiler can handle >

Re: PATCH to enable testing C++17 by default

On Oct 17, 2018, at 2:19 PM, Jeff Law wrote: >> 2018-10-17 Marek Polacek >> >> * g++.dg/*.C: Use target c++17 instead of explicit dg-options. >> * lib/g++-dg.exp: Don't test C++11 by default. Add C++17 to >> the list of default stds to test.Given this follows Jason's >>

<    1   2   3   4   5   6   7   8   9   10   >