g++-10 -v
Using built-in specs.
COLLECT_GCC=/opt/freeware/gcc-10.2.0/bin/g++-10
COLLECT_LTO_WRAPPER=/opt/freeware/gcc-10.2.0/libexec/gcc/powerpc-ibm-aix6.1.
9.0/10/lto-wrapper
Target: powerpc-ibm-aix6.1.9.0
Configured with: ../configure --prefix=/opt/freeware/gcc-10.2.0
--with-as=/usr/bin/as -
failing like this:
>
>
> >>
> >> > Executing on host:
> >> > /home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/xgcc
> >> > -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
> >> > /home/jenkins/gcc/gcc/testsuite/gcc.c-torture/
; > -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
>> > /home/jenkins/gcc/gcc/testsuite/gcc.c-torture/execute/2112-1.c
>> > gcc_tg.o-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
>> > -fdiagnostics-color=never -fdiagnostics-urls=never
ove in the original test. I am performing a new bootstrap
with the patch. Hopefully it will address some or all of the issues.
DejaGNU and the GCC testsuite is what it is. It is fragile. One of
the strengths of GCC is the wide variety of targets supported, not
only GNU/Linux, but o
> > -fdiagnostics-color=never -fdiagnostics-urls=never-O0 -w -msim {}
> > {} -
> > Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
> > ./2112-1.exe(timeout = 300)
> > spawn -ignore SIGHUP
> > /home/jenkins/workspace/c6x-elf
breakage on the embedded ports in the testsuite?
Essentially every test that links is failing like this:
> Executing on host: /home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/xgcc
> -B/home/jenkins/workspace/c6x-elf/c6x-elf-obj/gcc/gcc/
> /home/jenkins/gcc/gcc/testsuite/gcc.c-tortur
Hello, David,
On May 26, 2020, David Edelsohn wrote:
> Complaints about -dA, -dD, -dumpbase, etc.
This was the main symptom of the problem fixed in the follow-up commit
r11-635-g6232d02b4fce4c67d39815aa8fb956e4b10a4e1b
Could you please confirm that you did NOT have this commit in your
failing
Alexandre,
Your testsuite patches have completely broken the testsuite on AIX.
1000's of testsuite failures because the testsuite is inserting
unsupported options on AIX.
Complaints about -dA, -dD, -dumpbase, etc.
This patch was not properly tested on all targets. Please fix or
revert this patc
Hi!
Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
vs. "new") that ought to return identical results, I found that they
didn't:
@@ -75032,6 +75023,7 @@ PASS: g++.dg/expr/bitfield4.C -std=c++98 (test for
excess errors)
PASS:
On Mon, Feb 10, 2020 at 05:51:10PM +, Matthew Malcomson wrote:
> Just for anyone interested -- the manpage that describes the '!' is
> `gitglossary`.
>
> It's under the description of `pathspec`, and has a long-form of
> `:(exclude)`.
https://github.com/git/git/commit/93dbefb389a011c9107a39
On 08/02/2020 16:50, Segher Boessenkool wrote:
On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote:
"Jason" == Jason Merrill writes:
Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git
Jason> send-email command. I don't remember where I found that incantation.
Co
On Thu, 6 Feb 2020, Segher Boessenkool wrote:
> Instead of "git am" I had "patch -p1 <",
May I suggest "git apply" instead of the good old patch program.
(The "-p1" is of course built-in and you never have to do a
manual roll-back or separate --dry-run pass.)
brgds, H-P
require some simple markup in the commit message before the
> >>> changelogs? Maybe
> >>>
> >>> CL gcc/
> >>> * blablalba etc.
> >>> CL gcc/testsuite/
> >>> * gcc.target/...
> >>
> >>> etc.
> >>
On Sun, Feb 09, 2020 at 10:46:04AM +, Jonathan Wakely wrote:
> My main point was that Richi should be committing things, not working
> with uncommitted patches hanging around making things dirty.
>
> I like to use branches, but having a single branch with a series of
> commits that you reorder
On Sat, 8 Feb 2020 at 19:58, Segher Boessenkool
wrote:
>
> On Sat, Feb 08, 2020 at 09:46:53AM +1030, Alan Modra wrote:
> > On Fri, Feb 07, 2020 at 10:08:25AM +, Jonathan Wakely wrote:
> > > With Git you can't really have unwanted local commits present in a
> > > tree if you use a sensible work
On Sat, Feb 08, 2020 at 03:55:33PM -0800, Andrew Pinski wrote:
> On Sat, Feb 8, 2020 at 8:51 AM Segher Boessenkool
> wrote:
> >
> > On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote:
> > > > "Jason" == Jason Merrill writes:
> > >
> > > Jason> I omit ChangeLogs by adding ':!*/ChangeLo
On Sat, Feb 8, 2020 at 8:51 AM Segher Boessenkool
wrote:
>
> On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote:
> > > "Jason" == Jason Merrill writes:
> >
> > Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git
> > Jason> send-email command. I don't remember whe
On Sat, Feb 08, 2020 at 09:46:53AM +1030, Alan Modra wrote:
> On Fri, Feb 07, 2020 at 10:08:25AM +, Jonathan Wakely wrote:
> > With Git you can't really have unwanted local commits present in a
> > tree if you use a sensible workflow, so if you tested in a tree that
> > was at commit 1234abcd a
On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote:
> > "Jason" == Jason Merrill writes:
>
> Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git
> Jason> send-email command. I don't remember where I found that incantation.
>
> Cool, I did not know about this.
Y
On Fri, Feb 07, 2020 at 10:08:25AM +, Jonathan Wakely wrote:
> With Git you can't really have unwanted local commits present in a
> tree if you use a sensible workflow, so if you tested in a tree that
> was at commit 1234abcd and you push from another machine that is at
> the same commit, you k
> "Jason" == Jason Merrill writes:
Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git
Jason> send-email command. I don't remember where I found that incantation.
Cool, I did not know about this.
FWIW if you have the ChangeLog merger available, it's actually more
conve
On Fri, Feb 7, 2020 at 1:44 PM Tom Tromey wrote:
>
> > "Jonathan" == Jonathan Wakely writes:
>
> Jonathan> I have a script that does the opposite, which I've been using for
> Jonathan> years. I edit the ChangeLog files as before, and a Git
> Jonathan> prepare-commit-msg hook extracts the top
> "Jonathan" == Jonathan Wakely writes:
Jonathan> I have a script that does the opposite, which I've been using for
Jonathan> years. I edit the ChangeLog files as before, and a Git
Jonathan> prepare-commit-msg hook extracts the top changelog entry from each
Jonathan> file in the commit and pr
On Fri, Feb 07, 2020 at 03:43:05PM +, Richard Earnshaw (lists) wrote:
> On 07/02/2020 15:32, Segher Boessenkool wrote:
> >On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote:
> >>Any script should, in addition to extracting the author and email also
> >>grep for "Co-authore
gcc/testsuite/
* gcc.target/...
etc.
(Dunno if just "^CL " is too short?)
I was thinking "@CL ", but ^CL would work just as well.
I meant ^ as in a regular expression, sorry for not being clear.
Ah! I think something more syntactically explicit would help av
On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote:
> On 07/02/2020 13:48, Segher Boessenkool wrote:
> >Should we require some simple markup in the commit message before the
> >changelogs? Maybe
> >
> >CL gcc/
> > * b
in the ChangeLog files could be as easy as allowing
changes to ChangeLog files without that magic.
Yeah :-)
Anyway, I hope to put sth together with bash & [g]awk
gl;hf
Should we require some simple markup in the commit message before the
changelogs? Maybe
CL gcc/
* blablalba etc
still normal checked-in files, aha! That's a great idea. That
completely gets rid of my "fix mistakes" worries, and it will probably
also get rid of the "yet another flag day" inconvenience.
> Fixing mistakes in the ChangeLog files could be as easy as allowing
> changes to ChangeLog files without that magic.
Yeah :-)
> Anyway, I hope to put sth together with bash & [g]awk
gl;hf
Should we require some simple markup in the commit message before the
changelogs? Maybe
CL gcc/
* blablalba etc.
CL gcc/testsuite/
* gcc.target/...
etc.
(Dunno if just "^CL " is too short?)
Segher
On Fri, 7 Feb 2020 at 09:20, Richard Biener wrote:
>
> On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool
> wrote:
> > Instead of "git am" I had "patch -p1 <", distributing the changelog parts
> > I just did in vi (as with git), then "svn ci", which pick up all modified
> > files directly (someti
On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool
wrote:
>
> On Thu, Feb 06, 2020 at 03:01:20PM +0100, Richard Biener wrote:
> > On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool
> > wrote:
> > > If you rebase changelog files, then yes, it's a bloody pain ;-)
> >
> > So do you have a script that
On Thu, Feb 06, 2020 at 01:57:49PM -0500, Jason Merrill wrote:
> On Thu, Feb 6, 2020 at 11:25 AM Segher Boessenkool <
> seg...@kernel.crashing.org> wrote:
>
> >
> > We also need a way to fix changelog entries for the errors that do seep
> > through (and that are bad enough that they do need fixing
On Thu, Feb 06, 2020 at 03:01:20PM +0100, Richard Biener wrote:
> On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool
> wrote:
> > If you rebase changelog files, then yes, it's a bloody pain ;-)
>
> So do you have a script that takes a commit with a ChangeLog at its end
> and populates the appropri
On Thu, Feb 6, 2020 at 11:25 AM Segher Boessenkool <
seg...@kernel.crashing.org> wrote:
>
> We also need a way to fix changelog entries for the errors that do seep
> through (and that are bad enough that they do need fixing). It doesn't
> have to be easy or convenient, but we need *some* way to d
On Thu, Feb 06, 2020 at 10:17:54AM -0600, Segher Boessenkool wrote:
> > We would need to agree how do we express stuff going into different former
> > ChangeLog files, whether we require gcc/cp/ etc. prefixes before the lines,
> > or say require empty line for different former ChangeLog files and l
On Thu, Feb 06, 2020 at 03:56:40PM +0100, Jakub Jelinek wrote:
> On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote:
> > And FWIW, we're talking about the ChangeLog *file* here. If folks
> > continued writing the same log messages and put them into git, I
> > personally think that's sufficie
On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote:
> On Wed, 2020-02-05 at 15:18 -0600, Segher Boessenkool wrote:
> > On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote:
> > > ANd yes, even though I have been a regular ChangeLog user, I rely more
> > > and more on the git log these day
On Thu, 6 Feb 2020 at 14:01, Richard Biener wrote:
> So do you have a script that takes a commit with a ChangeLog at its end
> and populates the appropriate ChangeLog files? I'm trying to come up with
> one to make the process less manual ... it's definitely a part that requires
> more typing comp
On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool
wrote:
>
> On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote:
> > On Wed, 2020-02-05 at 15:18 -0600, Segher Boessenkool wrote:
> > > As a reviewer, the changelog is priceless still. We shouldn't drop the
> > > changelog before people write
On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote:
> On Wed, 2020-02-05 at 15:18 -0600, Segher Boessenkool wrote:
> > As a reviewer, the changelog is priceless still. We shouldn't drop the
> > changelog before people write *good* commit messages (and we are still
> > quite far from that goa
On Thu, Feb 06, 2020 at 08:51:42AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote:
> >> ANd yes, even though I have been a regular ChangeLog user, I rely more
> >> and more on the git log these days.
> >
> > As a reviewer,
On Wed, 2020-02-05 at 15:18 -0600, Segher Boessenkool wrote:
> On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote:
> > ANd yes, even though I have been a regular ChangeLog user, I rely more
> > and more on the git log these days.
>
> As a reviewer, the changelog is priceless still. We shoul
Segher Boessenkool writes:
> On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote:
>> ANd yes, even though I have been a regular ChangeLog user, I rely more
>> and more on the git log these days.
>
> As a reviewer, the changelog is priceless still. We shouldn't drop the
> changelog before peo
On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote:
> ANd yes, even though I have been a regular ChangeLog user, I rely more
> and more on the git log these days.
As a reviewer, the changelog is priceless still. We shouldn't drop the
changelog before people write *good* commit messages (and
On Mon, 2020-02-03 at 18:55 +, Richard Sandiford wrote:
> "H.J. Lu" writes:
> > On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
> > > On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
> > > > > > In my experience the output of git log is a total mess so cannot
> > > > > > replace Chan
"H.J. Lu" writes:
> On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
>>
>> On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
>> > > > In my experience the output of git log is a total mess so cannot
>> > > > replace ChangeLogs. But we can well decide to drop ChangeLog for
>> > > > the tes
On 2/3/20 5:15 AM, Richard Earnshaw (lists) wrote:
On 25/01/2020 16:11, Jeff Law wrote:
On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote:
On 1/24/20 4:36 PM, Jeff Law wrote:
On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
I strongly prefer to move towards relying on the git log
On 25/01/2020 16:11, Jeff Law wrote:
On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote:
On 1/24/20 4:36 PM, Jeff Law wrote:
On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
I strongly prefer to move towards relying on the git log.
In my experience the output of git log is a tota
On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote:
> On 1/24/20 4:36 PM, Jeff Law wrote:
> > On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
> > > > I strongly prefer to move towards relying on the git log.
> > >
> > > In my experience the output of git log is a total mess so cannot
On 1/24/20 4:36 PM, Jeff Law wrote:
On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
I strongly prefer to move towards relying on the git log.
In my experience the output of git log is a total mess so cannot replace
ChangeLogs. But we can well decide to drop ChangeLog for the testsuite
On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
>
> On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
> > > > In my experience the output of git log is a total mess so cannot
> > > > replace ChangeLogs. But we can well decide to drop ChangeLog for
> > > > the testsuite.
> > >
> > > Well,
On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
> > > In my experience the output of git log is a total mess so cannot
> > > replace ChangeLogs. But we can well decide to drop ChangeLog for
> > > the testsuite.
> >
> > Well, glibc has moved to extracting them from git, building
> > polici
On Fri, Jan 24, 2020 at 02:36:31PM -0700, Jeff Law wrote:
> On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
> > > I strongly prefer to move towards relying on the git log.
> >
> > In my experience the output of git log is a total mess so cannot replace
> > ChangeLogs. But we can well dec
On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
> > I strongly prefer to move towards relying on the git log.
>
> In my experience the output of git log is a total mess so cannot replace
> ChangeLogs. But we can well decide to drop ChangeLog for the testsuite.
Well, glibc has moved to ex
* Eric Botcazou:
>> I strongly prefer to move towards relying on the git log.
>
> In my experience the output of git log is a total mess so cannot replace
> ChangeLogs.
That's fixable if the commit message is part of the patch review
(just like the source code comments).
> I strongly prefer to move towards relying on the git log.
In my experience the output of git log is a total mess so cannot replace
ChangeLogs. But we can well decide to drop ChangeLog for the testsuite.
--
Eric Botcazou
es, but I'll add one for
> > > > the target-supports.exp change, thanks.
> > >
> > > Is this a general policy change that we want to make? Current we
> > > still have gcc/testsuite/ChangeLog and developers are updating that
> > > file.
&g
>>
>> Is this a general policy change that we want to make? Current we
>> still have gcc/testsuite/ChangeLog and developers are updating that
>> file.
>
> I would support formalizing that as policy; currently there is no policy.
>
> https://gcc.gnu.org/codingconven
te=state@entry=0x2fb7e000,
filename=filename@entry=0x7fffd8fc
"/home/uros/gcc-build/gcc/testsuite/go/index0-out.x",
descriptor=descriptor@entry=5,
base_address=base_address@entry=0,
error_callback=error_callback@entry=0x2b557450 ,
data=data@entry=0x2efda6a0,
On Sat, Sep 21, 2019 at 4:43 PM Martin Sebor wrote:
>
> On 9/21/19 2:34 PM, Martin Sebor wrote:
> > On 9/19/19 10:56 PM, Ian Lance Taylor wrote:
> >> On Thu, Sep 19, 2019 at 7:10 PM Martin Sebor wrote:
> >>>
> >>> All my Fedora 30 builds on x86_64 today have gotten stuck on
> >>> index0-out.x spi
On 9/21/19 2:34 PM, Martin Sebor wrote:
On 9/19/19 10:56 PM, Ian Lance Taylor wrote:
On Thu, Sep 19, 2019 at 7:10 PM Martin Sebor wrote:
All my Fedora 30 builds on x86_64 today have gotten stuck on
index0-out.x spinning indefinitely. I build and test all
languages, including Go, so I'm wonde
On 9/19/19 10:56 PM, Ian Lance Taylor wrote:
On Thu, Sep 19, 2019 at 7:10 PM Martin Sebor wrote:
All my Fedora 30 builds on x86_64 today have gotten stuck on
index0-out.x spinning indefinitely. I build and test all
languages, including Go, so I'm wondering if anyone else who
builds Go sees th
On Thu, Sep 19, 2019 at 7:10 PM Martin Sebor wrote:
>
> All my Fedora 30 builds on x86_64 today have gotten stuck on
> index0-out.x spinning indefinitely. I build and test all
> languages, including Go, so I'm wondering if anyone else who
> builds Go sees the same thing or if you know of a workar
All my Fedora 30 builds on x86_64 today have gotten stuck on
index0-out.x spinning indefinitely. I build and test all
languages, including Go, so I'm wondering if anyone else who
builds Go sees the same thing or if you know of a workaround.
Thanks
Martin
Hi!
I just stumbled over [1] and just wanted to add that Debian is reguarly
building snapshots of all current gcc versions for a large number of
targets, including the testsuites (except for m68k and sh4 at the moment).
The results can always be found on buildd.debian.org.
gcc-7:
https://buil
stuff and people make occassionally
> mistakes, that can happen to anyone. Admittedly some people repeat those
> mistakes often.
It's why I started doing those
gcc/testsuite/
things in the changelogs in the patches I send, to remind me what file
to apply what to. It helps :-)
> I
,7 +2502,7 @@
2019-07-12 Kewen Lin
- * gcc/cfgrtl.c (print_rtl_with_bb): Emit a hint if the
+ * cfgrtl.c (print_rtl_with_bb): Emit a hint if the
fallthrough target of current basic block isn't the placed
right next.
@@ -4453,18 +4452,11 @@
* con
Has there been a change of policy so it's a valid option to use
gcc/ChangeLog for testsuite changes? I was about to move a
semi-randomly spotted misplaced entry, and when checking if
there were others, I noticed that there's like tens of them, so
I thought better ask.
(IMHO it's confusing to have
Test results here:
https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg03095.html
Complete logs can be found here:
https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W
signature.asc
Description: OpenPGP digital signature
Am 17.01.2019 um 17:05 schrieb Rainer Emrich:
> I will try to do a bootstrap and testsuite run again on the next weekend.
Ok, it took a little longer. I've updated my msys2 installation and the
mingw-w64 runtime. The test results are for a resent msys2 installation
and mingw-w64 runtime master from
There was a bug which prevented building libgfortran. Now after the
issue is fixed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331,
I have posted new testresults.
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg01052.html
Compared to rev. 265163 we have the following changes:
acats tes
On Wed, 7 Nov 2018, Steve Ellcey wrote:
> I copied unix.exp to unix-sysroot.exp and added this to it:
>
> if {[info exists env(DEJAGNU_UNIX_SYSROOT_FLAGS)]} {
> set_board_info ldflags "$env(DEJAGNU_UNIX_SYSROOT_FLAGS)"
> }
>
> I figured I would deal with LOCPATH and GCONV_PATH later. When
>
in a directory
> > ($T) and
> > then I run the GCC testsuite with this command:
> >
> > # cd to GCC object directory
> > make -j50 check RUNTESTFLAGS="--tool_opts '--sysroot=$T -Wl,
> > --dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/li
On Wed, 7 Nov 2018, Steve Ellcey wrote:
> I have a question about the C++ library testsuite. I built and installed
> a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
> then I run the GCC testsuite with this command:
>
> # cd to GCC object directory
&g
I have a question about the C++ library testsuite. I built and installed
a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
then I run the GCC testsuite with this command:
# cd to GCC object directory
make -j50 check RUNTESTFLAGS="--tool_opts '--sysro
As promised, results are available here:
https://gcc.gnu.org/ml/gcc-testresults/2018-09/msg03636.html
Complete build and test logs are available for download here:
https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W
I keep the logs of some older revisions for comparison and added the
lo
On 05/02/2018 04:49 AM, Christian Groessler wrote:
> Hi,
>
> --- a/gcc/testsuite/gcc.c-torture/compile/simd-5.c
> +++ b/gcc/testsuite/gcc.c-torture/compile/simd-5.c
> @@ -6,7 +6,7 @@ main(){
> vector64 int a = {1, -1};
> vector64 int b = {2, -2};
> c = -a + b*b*(-1L
Hi,
--- a/gcc/testsuite/gcc.c-torture/compile/simd-5.c
+++ b/gcc/testsuite/gcc.c-torture/compile/simd-5.c
@@ -6,7 +6,7 @@ main(){
vector64 int a = {1, -1};
vector64 int b = {2, -2};
c = -a + b*b*(-1LL);
-/* c is now {5, 3} */
+/* c is now {-5, -3} */
printf("result is %llx\n", (l
On Jul 25, 2016, at 9:37 AM, Joseph Myers wrote:
>
> On Fri, 15 Jul 2016, Thomas Schwinge wrote:
>
>>> No, we want to have as little churn as possible in existing tests, the
>>> general policy is to add new tests (not just for OpenACC/OpenMP, but for
>>> all functionality).
>>
>> Hmm, that's so
On Fri, 15 Jul 2016, Thomas Schwinge wrote:
> > No, we want to have as little churn as possible in existing tests, the
> > general policy is to add new tests (not just for OpenACC/OpenMP, but for
> > all functionality).
>
> Hmm, that's something I had not been aware of, and I can't find this
> co
Hi!
Including in case others also have opinions on "GCC
testsuite maintenance".
On Fri, 15 Jul 2016 10:21:13 +0200, Jakub Jelinek wrote:
> On Fri, Jul 15, 2016 at 09:44:25AM +0200, Thomas Schwinge wrote:
> > Does that me we (erroneously) accept any random junk after [...]
Hi Andreas!
On Fri, 02 Oct 2015 13:58:55 +0200, Andreas Schwab
wrote:
> LAST_UPDATED: Fri Oct 2 02:31:25 UTC 2015 (revision 228367)
>
> Native configuration is aarch64-suse-linux-gnu
> === libgomp tests ===
>
>
> Running target unix
> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++
> Hi Marcus,
>
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeou
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300)
> spawn
On 18/08/15 10:45, Marcus Shawcroft wrote:
On 18 August 2015 at 10:25, Alex Velenko wrote:
On 31/07/15 12:04, Alex Velenko wrote:
On 29/07/15 23:14, Jeff Law wrote:
On 07/28/2015 12:18 PM, Alex Velenko wrote:
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrot
On 18 August 2015 at 10:25, Alex Velenko wrote:
>
>
> On 31/07/15 12:04, Alex Velenko wrote:
>>
>> On 29/07/15 23:14, Jeff Law wrote:
>>>
>>> On 07/28/2015 12:18 PM, Alex Velenko wrote:
On 21/04/15 06:27, Jeff Law wrote:
>
> On 04/20/2015 01:09 AM, Shiva Chen wrote:
>>
>>
On 31/07/15 12:04, Alex Velenko wrote:
On 29/07/15 23:14, Jeff Law wrote:
On 07/28/2015 12:18 PM, Alex Velenko wrote:
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
On 29/07/15 23:14, Jeff Law wrote:
On 07/28/2015 12:18 PM, Alex Velenko wrote:
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original
On 07/28/2015 12:18 PM, Alex Velenko wrote:
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.j
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl du
On Tue, 2015-04-28 at 22:58 +0200, Jakub Jelinek wrote:
> > I tried:
> >
> > export RUNTESTFLAGS='--target_board=multi-sim/--param\ foo=1'
> > export RUNTESTFLAGS='--target_board=multi-sim/--param/foo=1'
>
> Have you tried
> export RUNTESTFLAGS='--target_board=multi-sim/--param=foo=1'
> ?
>
>
On Tue, Apr 28, 2015 at 01:55:42PM -0700, Steve Ellcey wrote:
> Has anyone run the GCC testsuite using a --param option? I am trying
> to do something like:
>
> export RUNTESTFLAGS='--target_board=multi-sim/--param foo=1'
> make check
>
> But the space in the &#
Has anyone run the GCC testsuite using a --param option? I am trying
to do something like:
export RUNTESTFLAGS='--target_board=multi-sim/--param foo=1'
make check
But the space in the '--param foo=1' option is causing dejagnu to fail.
Perhaps there is a way to specify a p
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump
after patch can_replace_by.patch
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump
after patch can_replace_by.patch
Could you help me to review the patch?
Th
On 04/17/2015 03:57 AM, Shiva Chen wrote:
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_B
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_BASIC_BLOCK 5
32: [r6:SI]=r4:SI
REG_D
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
> > gcc/testsuite/
> > * g++.dg/guality/guality.exp (check_guality): Fix `test_counts'
> > restoration.
>
> Ok, thanks.
Applied, thanks.
Maciej
On Fri, Nov 14, 2014 at 09:01:25PM +, Maciej W. Rozycki wrote:
> 2014-11-14 Maciej W. Rozycki
>
> gcc/testsuite/
> * g++.dg/guality/guality.exp (check_guality): Fix `test_counts'
> restoration.
Ok, thanks.
> --- gcc-fsf-trunk-quilt.orig/gcc/t
On Mon, 15 Sep 2014, Jakub Jelinek wrote:
> 2014-09-14 Jakub Jelinek
>
> gcc/testsuite/
> * g++.dg/guality/guality.exp (check_guality): Save/restore
> test_counts array around the body of the procedure.
> * gcc.dg/guality/guality.exp (check_
> Hi,
>I couldn't find newlib in my source gcc-4.5.5 directory. I download
> and try to install it, i think it is not completed
> when i run make install ...it ends quickly with the message shown below
>
> make[2]: Leaving directory /gcc-4.4/build_newlib/etc'
> make[1]: Nothing to be done for
1 - 100 of 220 matches
Mail list logo
