On Wed, 27 May 2020 at 22:40, Alexandre Oliva wrote:
>
> On May 27, 2020, Christophe Lyon via Gcc wrote:
>
> > On Wed, 27 May 2020 at 16:26, Jeff Law via Gcc wrote:
>
> >> Any thoughts on the massive breakage on the embedded ports in the
> >> testsuite?
>
> I wasn't aware of any. Indeed, one o
On May 27, 2020, Christophe Lyon via Gcc wrote:
> On Wed, 27 May 2020 at 16:26, Jeff Law via Gcc wrote:
>> Any thoughts on the massive breakage on the embedded ports in the testsuite?
I wasn't aware of any. Indeed, one of my last steps before submitting
the patchset was to fix problems that h
On Wed, May 27, 2020 at 10:16 AM Alexandre Oliva wrote:
>
> 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
>
>
On Wed, 27 May 2020 at 16:26, Jeff Law via Gcc wrote:
>
> On Wed, 2020-05-27 at 11:16 -0300, Alexandre Oliva wrote:
> > 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 f
On Wed, 2020-05-27 at 11:16 -0300, Alexandre Oliva wrote:
> 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
>
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
>> Looks like I spoke too soon. It's hanging/spinning again. Do you
>> have any suggestion for how I can help debug it?
>
> Send the spinning process a SIGQUIT. It should crash with a stack
> backtrace showing what it is doing at that point.
I see a segfault in seemingly a random place, even wi
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
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,
>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
> Hi,
> These kinds of failures
> This failure is repeating again and again
>
> FAIL: gcc.c-torture/compile/990625-1.c -O0 (test for excess errors)
> Excess errors:
> /home/ash/rpm-root/packages/BUILD/gcc-4.4.5/gcc/testsuite/gcc.c-
> torture/compile/990625-1.c:2:20:
> error: string.h: No such fi
> 3. To run the testsuite :- sourcedir.../gcc-4.4.5/gcc
> make check
>
> It generates lot of failures
What kind of failures are you seeing? If possible could you have a
look at the *.log files in the testsuite directory and summarise the
errors you are seeing.
> Thanks & regards
> Mappy
Man
Andrew Haley writes:
> On 06/22/2012 03:27 PM, Ian Lance Taylor wrote:
>> Andrew Haley writes:
>>
>>> On 06/22/2012 11:35 AM, Simon Baldwin wrote:
Firstly, has anyone else encountered this or otherwise given it any
thought? And secondly, any hints for practical fixes?
>>>
>>> What yo
On 06/22/2012 03:27 PM, Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> On 06/22/2012 11:35 AM, Simon Baldwin wrote:
>>> Firstly, has anyone else encountered this or otherwise given it any
>>> thought? And secondly, any hints for practical fixes?
>>
>> What you effectively seem to be buildin
Andrew Haley writes:
> On 06/22/2012 11:35 AM, Simon Baldwin wrote:
>> Firstly, has anyone else encountered this or otherwise given it any
>> thought? And secondly, any hints for practical fixes?
>
> What you effectively seem to be building is a cross-compiler from
> x86-glibc-A to x86-glibc-B.
On 06/22/2012 11:35 AM, Simon Baldwin wrote:
> Firstly, has anyone else encountered this or otherwise given it any
> thought? And secondly, any hints for practical fixes?
What you effectively seem to be building is a cross-compiler from
x86-glibc-A to x86-glibc-B. To run your tests, you want a m
> Yes. I tried it in the order your used, and the compile to check
> for inttypes.h tried to also compile c_kinds.c, which wasn't
> available from where the compile was done. In general it's best
> to check effective targets before adding files or options, unless
> the options are required for th
On Mon, 2007-08-06 at 13:16 -0700, Steve Ellcey wrote:
> > and the test runs on powerpc64-linux for both -m32 and -m64. Did
> > you have it in a different position? If so I'll try that and see
> > if I can figure out why it would be skipped. Also, which target
> > were you testing?
>
> I was te
> and the test runs on powerpc64-linux for both -m32 and -m64. Did
> you have it in a different position? If so I'll try that and see
> if I can figure out why it would be skipped. Also, which target
> were you testing?
I was testing on an IA64 Linux platform (Debian). I had this:
! { dg-do r
On Mon, 2007-08-06 at 10:28 -0700, Steve Ellcey wrote:
> I am running into a problem running the gfortran.dg/c_kind_params.f90
> and am wondering how to address it. This test has a C language
> component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
> uses types like int32_t and int
On Wed, Oct 18, 2006 at 11:22:40PM +0200, Bernhard Fischer wrote:
> Hi,
>
> I need to check for a non-0 return value in dg-compile testcases in
> gcc.
The compiler's exit status is only known within code from the DejaGnu
product, in proc default_target_compile in DejaGnu's target.exp. If
there w
On Oct 18, 2006, at 2:22 PM, Bernhard Fischer wrote:
I need to check for a non-0 return value in dg-compile testcases in
gcc.
I'd not worry about it in general. The exit status should be properly
checked for every other compile line and it should be ok.
On Tue, Sep 05, 2006 at 01:27:45PM -0700, Steve Ellcey wrote:
> I am not sure what the 'right' way to do this is. I wound up editing
> /usr/share/dejagnu/remote.exp to change 'set timeout 300' to 'set
> timeout 2000' and I edited /usr/share/dejagnu/config/unix.exp to change
> 'set status [remote_
> From: Rask Ingemann Lambertsen <[EMAIL PROTECTED]>
>
>In case it isn't obvious, I have little or no clue about tcl, expect and
> dejagnu. The only time that I've had success in modifying the timeout was by
> adding this to /usr/share/dejagnu/baseboards/unix.exp:
>
> set_board_info gcc,timeou
On Tue, Aug 30, 2005 at 05:44:52PM -0700, Mike Stump wrote:
> On Aug 30, 2005, at 4:34 PM, Steve Ellcey wrote:
> >I see that it is timing out on a slow machine that I have. I tried
> >to look around to find out how and where the timeout limit was set
> >and could not find it.
[snip]
> M-x gr
On Wed, Jan 25, 2006 at 09:06:06AM -0500, Diego Novillo wrote:
> Paolo Bonzini wrote:
> > I suppose. I don't understand why can't you just look in
> > stage3-gcc/testsuite, but I guess you know what you're doing. :-)
> >
> Hmm, now that I think about it again. The log contains command lines
> tha
Paolo Bonzini wrote:
> I suppose. I don't understand why can't you just look in
> stage3-gcc/testsuite, but I guess you know what you're doing. :-)
>
Hmm, now that I think about it again. The log contains command lines
that use the compiler built in /gcc. Something like
/gcc/testsuite/gfortran/.
So, I would just need to move /gcc/testsuite into /stage1-gcc?
I suppose. I don't understand why can't you just look in
stage3-gcc/testsuite, but I guess you know what you're doing. :-)
Also note that with my patch you could do make check-fortran: all the
targets for the disabled languag
Paolo Bonzini wrote:
> Because all the gcc directory has been relocated in stage3-gcc. It
> allows you for example to run the testsuite for stage2 and then to
> compare stage2 and stage3 results, for example.
>
Ah, OK.
> No, it will allow you to do "make cc1plus" or "make f951" within the
> build
Diego Novillo wrote:
Paolo Bonzini wrote:
I believe it was only relocated in stage3-gcc/testsuite.
Huh. Any reason in particular? Why not leave it in /gcc?
Because all the gcc directory has been relocated in stage3-gcc. It
allows you for example to run the testsuite for stage2 a
Paolo Bonzini wrote:
> I believe it was only relocated in stage3-gcc/testsuite.
Huh. Any reason in particular? Why not leave it in /gcc?
> Right now to change the STAGE1_LANGUAGES, you have to remove the
> stage1-gcc directory. I have a patch to fix this; I'm not sure that
> the slush is the bes
I tried 'make all-stage1 STAGE1_LANGUAGES=c++,fortran'. Not only that
didn't work, it wiped the directory /gcc/testsuite.
I believe it was only relocated in stage3-gcc/testsuite.
Right now to change the STAGE1_LANGUAGES, you have to remove the
stage1-gcc directory. I have a patch to fix this
> Yes, I think you are right. I can see a substantial slowdown in
> compilation times on IA64 HP-UX at -O2 (though it doesn't time out
> there).
>
> gcc 4.0.0 - 81 seconds
> gcc 3.4.1 - 38 seconds
> gcc 3.4.0 - 37 seconds
> gcc 3.3.5 - 89 seconds
> gcc 3.3.1 - 91 seconds
>
> 3.3 is slow, 3.4 is fa
> > By hand, I can compile the test in about 3 1/2 minutes on the machine in
> > question (the machine may have been busier when the failure occured and thus
> > taken longer).
>
> I think it's a real regression (memory consumption/speed) of the compiler, it
> is timing out on all the slow SPARC
> By hand, I can compile the test in about 3 1/2 minutes on the machine in
> question (the machine may have been busier when the failure occured and thus
> taken longer).
I think it's a real regression (memory consumption/speed) of the compiler, it
is timing out on all the slow SPARC machines I
On Aug 30, 2005, at 4:34 PM, Steve Ellcey wrote:
I see that it is timing out on a slow machine that I have. I tried
to look around to find out how and where the timeout limit was set
and could not find it. Can someone explain to me how much time a
compile is given and where this limit is s
40 matches
Mail list logo
