-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.03.2015 18:30, schrieb Rainer Emrich:
> Am 25.03.2015 17:22, schrieb Kai Tietz:
>> Hmm, this seems to be something I haven't noticed until now. It might
>> be new ... I see that cp-tree.h is part of gtfiles in config-lang.in. So
>> the warning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.03.2015 17:22, schrieb Kai Tietz:
> Hmm, this seems to be something I haven't noticed until now. It might be
> new ... I see that cp-tree.h is part of gtfiles in config-lang.in. So the
> warning about being not tagged for that language is weir
Hmm, this seems to be something I haven't noticed until now. It might
be new ...
I see that cp-tree.h is part of gtfiles in config-lang.in. So the
warning about being not tagged for that language is weird. Issue
might be not directly within gcc.
Instead it might be a make issue.
You could ask on
On Sun, Jan 19, 2014 at 07:39:12PM +0100, Winfried Magerl wrote:
> Hi,
>
> since "trunk revision 206525" I'm unable to bootstrap
> gcc with '-O3' as optimisation. No problem until
> revision 2065250.
>
> From the diff-output it looks like this entry from
> ChangeLog is the only candidate:
>
> --
On Tue, Nov 12, 2013 at 11:52 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote:
>> On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>>
>> > > Unfortunately, we are not able to keep up with the old kernels.
>> > > Two possible ways to go:
>> > > - disable li
On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote:
> On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>
> > > Unfortunately, we are not able to keep up with the old kernels.
> > > Two possible ways to go:
> > > - disable libsanitizer on older kernels
> > > - someone needs to work wit
[text-only]
On Sun, Nov 10, 2013 at 10:34 PM, FX wrote:
>> Unfortunately, we are not able to keep up with the old kernels.
>> Two possible ways to go:
>> - disable libsanitizer on older kernels
>> - someone needs to work with us in upstream repository (llvm) to keep the
>> code old-kernel-comp
> Unfortunately, we are not able to keep up with the old kernels.
> Two possible ways to go:
> - disable libsanitizer on older kernels
> - someone needs to work with us in upstream repository (llvm) to keep the
> code old-kernel-compatible
(It appears to be not only kernel, but binutils.)
I th
[resending text-only]
On Sun, Nov 10, 2013 at 8:51 AM, Konstantin Serebryany
wrote:
> Unfortunately, we are not able to keep up with the old kernels.
> Two possible ways to go:
> - disable libsanitizer on older kernels
> - someone needs to work with us in upstream repository (llvm) to keep th
> In principle, you could try --disable-libsanitizer
> --disable-target-libsanitizer but I am not sure whether that works, a
> fortnight ago, Janne remarked at #gcc that it didn't seem to work – maybe you
> have more luck.
>
> Your Linux 2.6.18 is already quite old (September 2007) thus I would
FX wrote:
I’m building with binutils 2.17.50.0.6, which is a bit old but I cannot find
any mention of needing later binutils on the installation notes.
Is bootstrap broken, or am I missing something?
Second build, this time with trunk binutils. Still fails in libsanitizer at
stage1, this time
> I’m building with binutils 2.17.50.0.6, which is a bit old but I cannot find
> any mention of needing later binutils on the installation notes.
> Is bootstrap broken, or am I missing something?
Second build, this time with trunk binutils. Still fails in libsanitizer at
stage1, this time with:
On Fri, Sep 6, 2013 at 7:40 AM, Jan Hubicka wrote:
>> On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote:
>> > > > .. looks like this is target/58269, which therefore affects
>> > > > x86_64-linux too.
>> > >
>> > > Now this reproduces to me, too. apppy_args expansion is trying to
>> >
> On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote:
> > > > .. looks like this is target/58269, which therefore affects
> > > > x86_64-linux too.
> > >
> > > Now this reproduces to me, too. apppy_args expansion is trying to
> > > preserve AVX
> > > register in V8SF mode when AVX is di
On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote:
> > > .. looks like this is target/58269, which therefore affects
> > > x86_64-linux too.
> >
> > Now this reproduces to me, too. apppy_args expansion is trying to preserve
> > AVX
> > register in V8SF mode when AVX is disabled. This
> > .. looks like this is target/58269, which therefore affects
> > x86_64-linux too.
>
> Now this reproduces to me, too. apppy_args expansion is trying to preserve
> AVX
> register in V8SF mode when AVX is disabled. This leads to move expander to
> not
> allow moving it and we end up infinite
> .. looks like this is target/58269, which therefore affects
> x86_64-linux too.
Now this reproduces to me, too. apppy_args expansion is trying to preserve AVX
register in V8SF mode when AVX is disabled. This leads to move expander to not
allow moving it and we end up infinitely recursing tryin
Hi,
On 09/06/2013 01:46 PM, Peter Bergner wrote:
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote:
. on x86_64-linux, this commit broke the build of that file:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
CC-ing Peter.
Can you try the patch that HJ suggested?
http://gcc.gnu.
On Fri, 2013-09-06 at 13:36 +0200, Paolo Carlini wrote:
> . on x86_64-linux, this commit broke the build of that file:
>
> http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
>
> CC-ing Peter.
Can you try the patch that HJ suggested?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139#c9
Peter
. on x86_64-linux, this commit broke the build of that file:
http://gcc.gnu.org/ml/gcc-cvs/2013-09/msg00149.html
CC-ing Peter.
Thanks,
Paolo.
.. looks like this is target/58269, which therefore affects
x86_64-linux too.
Paolo.
Like this. Tested on powerpc-linux and installed as obvious.
Andreas.
* include/Makefile.am (${host_builddir}/c++config.h): Replace
[] by [].
* include/Makefile.in: Regenerate.
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 44200ee
On Tue, Dec 4, 2012 at 5:22 PM, Andreas Schwab wrote:
> Steven Bosscher writes:
>
>> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
>
> I think if you had changed to it would have a
> better chance to survive broken editors.
I only put back what was there before. To be hones
Steven Bosscher writes:
> Fixed with http://gcc.gnu.org/viewcvs?view=revision&revision=194152
I think if you had changed to it would have a
better chance to survive broken editors.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D
Steven Bosscher writes:
> Looks like someone used a broken editor replacing tabs with spaces:
Rather the other way round.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different.
On Tue, Dec 4, 2012 at 4:47 PM, Steven Bosscher wrote:
> On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
>> Hello,
>>
>> Someone broke bootstrap on powerpc64-linux between r194084 and
>> r194141. Anyone else seeing this?
>>
>> Ciao!
>> Steven
>
> Looks like someone used a broken editor repla
On Tue, Dec 4, 2012 at 4:44 PM, Steven Bosscher wrote:
> Hello,
>
> Someone broke bootstrap on powerpc64-linux between r194084 and
> r194141. Anyone else seeing this?
>
> Ciao!
> Steven
Looks like someone used a broken editor replacing tabs with spaces:
2012-12-03 Benjamin Kosnik
* i
Committed in r192788.
Thanks,
Sharad
Sharad
On Wed, Oct 24, 2012 at 4:02 PM, Sharad Singhai wrote:
> I thought Steven was going to do that. If not, I can apply it.
>
> Thanks,
> Sharad
> Sharad
>
>
> On Wed, Oct 24, 2012 at 4:00 PM, David Edelsohn wrote:
>> Is someone going to apply this patch
I thought Steven was going to do that. If not, I can apply it.
Thanks,
Sharad
Sharad
On Wed, Oct 24, 2012 at 4:00 PM, David Edelsohn wrote:
> Is someone going to apply this patch?
>
> Thanks, David
>
> On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
>> On Wed, Oct 24, 2012 at 2:13 PM, S
Is someone going to apply this patch?
Thanks, David
On Wed, Oct 24, 2012 at 5:18 PM, Sharad Singhai wrote:
> On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher
> wrote:
>> Hello,
>>
>> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
>> rs6000_density_test(rs6000_cost_data*)':
>> ../../
On Wed, Oct 24, 2012 at 2:13 PM, Steven Bosscher wrote:
> Hello,
>
> ../../trunk/gcc/config/rs6000/rs6000.c: In function 'void
> rs6000_density_test(rs6000_cost_data*)':
> ../../trunk/gcc/config/rs6000/rs6000.c:3550:32: error: 'dump_kind_p'
> was not declared in this scope
>
> This is due to:
>
>
On 23.09.12 18:24, Richard Guenther wrote:
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
wrote:
Hi all,
while testing some patches fro Michael M, I noticed that disable-checking
seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
Is this issue already known?
If not,
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
wrote:
> Hi all,
>
> while testing some patches fro Michael M, I noticed that disable-checking
> seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
>
> Is this issue already known?
> If not, usual bug report with preprocessed
On Tue, 4 Sep 2012, Steven Bosscher wrote:
> Also, on at least powerpc64-unknown-linux-gnu (a primary platform) and
> sparc64-unknown-linux-gnu and probably others (PR54453). The breakage
> is caused by drepper's patches at r190783 and r190787. The breakage
> on powerpc64 is now almost a week old
On 07/10/2010 05:01, Dave Korn wrote:
>
> FYI, in case anyone else runs into this and comes here looking for
> information: a fix is on the way for the "multiple definitions of various
> include-path-related things" problem currently breaking bootstrap on Cygwin.
> Hope to have it working again
Hi Jack,
Jack Howarth wrote:
You didn't show the configure options you used to build gcc trunk
against the fink libraries. You need at least...
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Note that we don't set CPP
On Mon, Jun 01, 2009 at 12:07:56PM +0200, Tobias Schlüter wrote:
>
> Hi,
>
> I'm seeing this error:
>
> /Users/tobi/src/hggcc/build/./prev-gcc/xgcc
> -B/Users/tobi/src/hggcc/build/./prev-gcc/
> -B/usr/local/i386-apple-darwin8.11.1/bin/
> -B/usr/local/i386-apple-darwin8.11.1/bin/
> -B/usr/lo
Joseph S. Myers wrote:
On Mon, 1 Jun 2009, Tobias Schlüter wrote:
The complaint is about:
ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
[...snip...]
iconv_ret = iconv (cd, &inbuf, &inbytesleft,
&outbuf, &outbytes
Tobias Schlüter wrote:
> cc1: warnings being treated as errors
> ../../gcc/pretty-print.c: In function 'identifier_to_locale':
> ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv'
> from incompatible pointer type
> /sw/include/iconv.h:83: note: expected 'char **' but argument i
On Mon, 1 Jun 2009, Tobias Schlüter wrote:
> The complaint is about:
> ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
> [...snip...]
> iconv_ret = iconv (cd, &inbuf, &inbytesleft,
>&outbuf, &outbytesleft);
The types are ex
Dave Korn wrote:
Tim Prince wrote:
#include
no such file
-I/include was set by configure. As you say, there is something bogus here.
setup menu shows cloog installed in development category, but I can't find
any such include file. Does this mean the cygwin distribution of cloog is
broke
Tim Prince wrote:
>
> #include
>
> no such file
> -I/include was set by configure. As you say, there is something bogus here.
>
> setup menu shows cloog installed in development category, but I can't find
> any such include file. Does this mean the cygwin distribution of cloog is
> broken?
Dave Korn wrote:
> Tim Prince wrote:
>> Dave Korn wrote:
>>
>>> Heh, I was just about to post that, only I was looking at $clooginc rather
>>> than $pplinc! The same problem exists for both; I'm pretty sure we should
>>> fall back on $prefix if the --with option is empty.
>>>
>> When I bootstrap
Tim Prince wrote:
> Dave Korn wrote:
>
>> Heh, I was just about to post that, only I was looking at $clooginc rather
>> than $pplinc! The same problem exists for both; I'm pretty sure we should
>> fall back on $prefix if the --with option is empty.
>>
>
> When I bootstrapped gcc 4.5 on cygwin
Dave Korn wrote:
>
> Heh, I was just about to post that, only I was looking at $clooginc rather
> than $pplinc! The same problem exists for both; I'm pretty sure we should
> fall back on $prefix if the --with option is empty.
>
When I bootstrapped gcc 4.5 on cygwin yesterday, configure recog
Andreas Schwab wrote:
> Dave Korn writes:
>
>> I'm about to start looking through the config logs; if anyone knows
>> anything
>> or has any ideas about this, please share!
>
> The problem is here in toplevel configure.ac:
>
> case $with_ppl in
> no)
> ppllibs=
> ;;
> *)
> p
Dave Korn writes:
> I'm about to start looking through the config logs; if anyone knows anything
> or has any ideas about this, please share!
The problem is here in toplevel configure.ac:
case $with_ppl in
no)
ppllibs=
;;
*)
ppllibs="-L$with_ppl/lib -lppl_c -lppl -lgmpxx $wit
On Sun, 5 Apr 2009, Laurent GUERBY wrote:
> I'm thinking of changing my auto tester to report a broken bootstrap
> (the first time a bootstrap fails), is there a normalized way to
> report such failures to gcc-testresults@ or g...@?
The "regression" component in Bugzilla exists for automatic repo
On Sun, Apr 5, 2009 at 2:25 AM, Laurent GUERBY wrote:
> Hi,
>
> On sparc-linux gcc54 I get at rev 145425:
>
> /home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/
> -B/n/54/guerby/install-trunk/sparc64-unknown-linux-gnu/bin/ -c -g -O2
> -DIN_GCC -W -Wall -Wwrite-strings -Wstric
Kai Tietz <[EMAIL PROTECTED]> writes:
> or: in vt_add_function_parameters, at var-tracking.c:3176
This is PR37815.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44
On Thu, 2008-08-14 at 14:41 -0700, H.J. Lu wrote:
> It should be fixed now.
Thanks a lot for the quick fix.
My problem is that I don't have access to a machine with GFC_REAL_16 and
working autoconf2.59, so possible problems in cut&paste code tend to be
hidden from me.
I'll make special mention
On Thu, Aug 14, 2008 at 1:32 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Failure:
>
> ../../../libgfortran/intrinsics/cshift0.c: In function 'cshift0':
> ../../../libgfortran/intrinsics/cshift0.c:124: warning: passing
> argument 1 of 'cshift0_i16' from incompatible pointer type
> ../../../libgfo
2008/5/23 Art Haas <[EMAIL PROTECTED]>:
> On Thu, 2008-05-22 at 21:12, Kai Tietz wrote:
>> Art,
>>
>> 2008/5/22 Art Haas <[EMAIL PROTECTED]>:
>> >
>> > On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
>> >> Ok, fixed on gcc trunk revision 135776.
>> >
>> > The patch fixed the warning error, but the bo
On Thu, 2008-05-22 at 21:12, Kai Tietz wrote:
> Art,
>
> 2008/5/22 Art Haas <[EMAIL PROTECTED]>:
> >
> > On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
> >> Ok, fixed on gcc trunk revision 135776.
> >
> > The patch fixed the warning error, but the bootstrap is still
> broken:
> >
> > { ... snip ...
On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
> Ok, fixed on gcc trunk revision 135776.
The patch fixed the warning error, but the bootstrap is still broken:
{ ... snip ... }
cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4845: error:
'return_in_memory
Art,
2008/5/22 Art Haas <[EMAIL PROTECTED]>:
> Hi.
>
> I've been unable to successfully bootstrap on my i386-pc-solaris2.10
> system since this set of changes made it into the repository:
>
> 2008-05-20 Kai Tietz <[EMAIL PROTECTED]>
>
>* config/i386/i386-protos.h (ix86_return_in_memory):
On Feb 20, 2008 10:15 AM, Danny Smith <[EMAIL PROTECTED]> wrote:
>
> On Feb 20, 2008 10:02 PM, Danny Smith <[EMAIL PROTECTED]> wrote:
> > On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > >
> > > gcc/ChangeLog:
> > > 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
> > >
> >
On Feb 20, 2008 10:02 PM, Danny Smith <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > gcc/ChangeLog:
> > 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
> >
> > PR bootstrap/35218
> > * Makefile.in (build_file_translate): Ne
On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> gcc/ChangeLog:
> 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
>
> PR bootstrap/35218
> * Makefile.in (build_file_translate): New.
> (gcc-vers.texi): Use it for translating $(abs_srcdir).
> *
Weddington, Eric wrote:
Yes, because the one provided with MSYS is from texinfo 4.3, which
GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo
4.11, but it's still labeled "technology preview" for now.
I'm in the same boat here, msys-1.0.10, texinfo 4.3.
Is it the case that
* Joseph S. Myers wrote on Sun, Feb 17, 2008 at 11:42:34PM CET:
> On Sun, 17 Feb 2008, Ralf Wildenhues wrote:
>
> > So, here's another alternative: fix the MinGW issue only, while not
> > regressing on any of the other reported bug (famous last words):
> > One way for path translation on MinGW wou
Lamo, Jo Inge; [EMAIL PROTECTED]
> Subject: Re: bootstrap broken on mingw
>
> * Weddington, Eric wrote on Sun, Feb 17, 2008 at 11:08:58PM CET:
>
> > I'm tyring out your new patch now...
>
> Thanks. BTW, if it works, OK for trunk and 4.2? If that
> does not work
On Sun, 17 Feb 2008, Ralf Wildenhues wrote:
> So, here's another alternative: fix the MinGW issue only, while not
> regressing on any of the other reported bug (famous last words):
> One way for path translation on MinGW would be to use
> CMD //c echo "@set srcdir" "$(abs_srcdir)"
If the abs_sr
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 11:08:58PM CET:
>
> No it wouldn't. I don't understand why reverting the patch would cause
> havoc. The 20080208 snapshot built just fine, even with an old texinfo
> version. I'd rather go back to that behaviour.
It didn't for me, with texinfo 4.8,
; [EMAIL PROTECTED]
> Subject: Re: bootstrap broken on mingw
>
> * Ralf Wildenhues wrote on Sun, Feb 17, 2008 at 10:59:07PM CET:
> > * Weddington, Eric wrote on Sun, Feb 17, 2008 at 10:30:24PM CET:
> > > Is there any reason why we can't revert the patch that
> c
* Ralf Wildenhues wrote on Sun, Feb 17, 2008 at 10:59:07PM CET:
> * Weddington, Eric wrote on Sun, Feb 17, 2008 at 10:30:24PM CET:
> > Is there any reason why we can't revert the patch that caused this?
>
> Well if we do then we need to reopen PR 35148 which would be equivalent
> to requiring texi
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 10:30:24PM CET:
>
> Ok. I did the above and ran autoconf in the /gcc subdir. I got this
> error:
>
> if [ xinfo = xinfo ]; then \
> makeinfo --split-size=500 --split-size=500 --no-split -I
> . -I ../../gcc-4.3-20080215/gcc/doc \
>
Lamo, Jo Inge; [EMAIL PROTECTED]
> Subject: Re: bootstrap broken on mingw
>
> * Weddington, Eric wrote on Sun, Feb 17, 2008 at 08:41:02PM CET:
> > >
> > > I'm willing to try, but running "autoconf" doesn't
> regenerate the
> > > configure f
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 08:32:26PM CET:
>
> With that patch I'm now getting:
>
> (echo "@set version-GCC 4.3.0"; \
> if [ "experimental" = "experimental" ]; \
> then echo "@set DEVELOPMENT"; \
> else echo "@clear DEVELOPMENT"; \
> fi) > gcc-vers.texiT
> /bin/sh: buil
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 08:41:02PM CET:
> >
> > I'm willing to try, but running "autoconf" doesn't regenerate the
> > configure file, what am I missing?
>
> I do:
>
> aclocal
> autoconf
>
> At the top level. aclocal 1.9.6, autoconf 2.59.
You need to run autoconf in t
Lamo, Jo Inge; [EMAIL PROTECTED]
> Subject: Re: bootstrap broken on mingw
>
> > gcc/ChangeLog:
> > 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
> >
> > PR bootstrap/35218
> > * Makefile.in (build_file_translate): New.
> >
> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 11:05 AM
> To: FX Coudert
> Cc: Richard Guenther; Joerg Wunsch; GCC Development;
> Weddington, Eric; Denis Chertykov; Anatoly Sokolov; Lamo, Jo Inge
> Subject:
> -Original Message-
> From: FX Coudert [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 11:00 AM
> To: Ralf Wildenhues
> Cc: Richard Guenther; Joerg Wunsch; GCC Development;
> Weddington, Eric; Denis Chertykov; Anatoly Sokolov; Lamo, Jo Inge
> Subject:
gcc/ChangeLog:
2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
PR bootstrap/35218
* Makefile.in (build_file_translate): New.
* config.build (build_file_translate): Set to `CMD //c' on MinGW.
* configure.ac (build_file_translate): Substitute it.
* configure
* FX Coudert wrote on Sun, Feb 17, 2008 at 06:59:49PM CET:
>
> >If not, another
> >possibility would be to just require users on MinGW to update their
> >system texinfo installation.
>
> Weeks before the release? That doesn't give much time to anyone for
> getting it working and actually testin
One question I have, Eric and FX: do you both have self-built
texinfo on
MinGW?
Yes, because the one provided with MSYS is from texinfo 4.3, which
GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo
4.11, but it's still labeled "technology preview" for now.
Because the spe
[ adding gcc-patches ]
* Gerald Pfeifer wrote on Sun, Feb 17, 2008 at 02:46:45PM CET:
> On Sun, 17 Feb 2008, Ralf Wildenhues wrote:
> > I see two possibilities: revert above patch, and list texinfo 4.11 as
> > prerequisite for building the pdf/dvi
>
> I'm not in favor of making texinfo 4.11 a req
On Sun, 17 Feb 2008, Ralf Wildenhues wrote:
> I see two possibilities: revert above patch, and list texinfo 4.11 as
> prerequisite for building the pdf/dvi
I'm not in favor of making texinfo 4.11 a requirement. As far as I can
see it was released less than half a year ago and even recent release
* FX Coudert wrote on Sun, Feb 17, 2008 at 12:54:05PM CET:
> >Actually there seems to be a recent change "backward" to that logic:
> >
> >2008-02-13 Ralf Wildenhues <[EMAIL PROTECTED]>
> >
> >PR other/35148
> >* Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of
> >
Actually there seems to be a recent change "backward" to that logic:
2008-02-13 Ralf Wildenhues <[EMAIL PROTECTED]>
PR other/35148
* Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of
srcdir.
Doesn't look too good for mingw.
and we have PR35218 which seems
On Feb 17, 2008 12:41 PM, FX Coudert <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I also see this failure on a native build for i386-pc-mingw32, so
> this is probably a mingw issue. Since i686-pc-mingw32 is a seconday
> platform, this makes it a release blocker (I've marked it as such in
> bugzilla, an
Richard Sandiford <[EMAIL PROTECTED]> writes:
> David Daney <[EMAIL PROTECTED]> writes:
>> For r131631 bootstrap on mipsel-linux in stage2 I am getting:
>>
>> [...]
>> ../../trunk/gcc/global.c:1020: error: array subscript is above array bounds
>> make[3]: *** [global.o] Error 1
>>
>> This is new si
On Sat, Jan 19, 2008 at 11:10:11AM -0800, David Daney wrote:
> For r131631 bootstrap on mipsel-linux in stage2 I am getting:
>
> /home/ddaney/gccsvn/trunk-build/./prev-gcc/xgcc
> -B/home/ddaney/gccsvn/trunk-build/./prev-gcc/
> -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -c -g -O2 -DIN
David Daney <[EMAIL PROTECTED]> writes:
> For r131631 bootstrap on mipsel-linux in stage2 I am getting:
>
> /home/ddaney/gccsvn/trunk-build/./prev-gcc/xgcc
> -B/home/ddaney/gccsvn/trunk-build/./prev-gcc/
> -B/home/ddaney/gccsvn/trunk-install/mipsel-linux/bin/ -c -g -O2
> -DIN_GCC -W -Wall -W
> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
> > bootstrap with current svn head fails for me on Linux/x86-64:
> ...
> > cc1: warnings being treated as errors
> > /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error:
> > ???treelang_expand_function??? defined but not used
> > make[3]: *** [tr
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> bootstrap with current svn head fails for me on Linux/x86-64:
...
> cc1: warnings being treated as errors
> /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error:
> ‘treelang_expand_function’ defined but not used
> make[3]: *** [treelang/treetree.o] E
On Thu, 2007-09-06 at 15:32 +0200, Christian Joensson wrote:
> 2007/9/6, Sandra Loosemore <[EMAIL PROTECTED]>:
> > Christian Joensson wrote:
> > > Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a
> > > bootstrap failure:
> > >
> > > ../../gcc/gcc/ada/trans.c: In function `conv
2007/9/6, Sandra Loosemore <[EMAIL PROTECTED]>:
> Christian Joensson wrote:
> > Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a
> > bootstrap failure:
> >
> > gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
> > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
Christian Joensson wrote:
Using checkout Thu Sep 6 05:56:16 UTC 2007 (revision 128174), I get a
bootstrap failure:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-DHAVE_CONFIG_H -I. -Iada -I../../gcc/gcc -I../../gcc/gcc/ada
-I../
On Tue, 2007-07-24 at 11:23 +0200, Thomas Veith wrote:
> Hi *,
>
> bootstrap is broken on trunk rev. 126866 during Stage3:
Thanks. This has been fixed by Tobias Burnus with
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00736.html
.
Hi Thomas,
> bootstrap is broken on trunk during stage1:
Seems to be not in general. It is related to the whitespaces for the new
types used in splay-tree.h. If shrink them, it seems to work as Uros
detected. This smells, that the gengtype-lex.l has problems about too much
spaces in a typedef.
On Thu, Jul 05, 2007 at 07:36:24PM +0300, Dorit Nuzman wrote:
>> Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
>> 17:46:45:
>>
>>> On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
>> checking whether the GNU Fort
> Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
> 17:46:45:
>
> > On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> > > Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> > >
> > > > > checking whether the GNU Fortran compiler is working... no
> > > > > configure: error: GN
Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
17:46:45:
> On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> > Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> >
> > > > checking whether the GNU Fortran compiler is working... no
> > > > configure: error: GNU Fortran is no
On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
>
> > > checking whether the GNU Fortran compiler is working... no
> > > configure: error: GNU Fortran is not working; please report a bug in
> > > http://gcc.gnu.org/bugzilla, att
Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> > checking whether the GNU Fortran compiler is working... no
> > configure: error: GNU Fortran is not working; please report a bug in
> > http://gcc.gnu.org/bugzilla, attaching
> > /Develop/mainline-dn/build3/powerpc64-unknown-linux-
> gnu/li
> checking whether the GNU Fortran compiler is working... no
> configure: error: GNU Fortran is not working; please report a bug in
> http://gcc.gnu.org/bugzilla, attaching
>
/Develop/mainline-dn/build3/powerpc64-unknown-linux-gnu/libgfortran/config.log
> make[1]: *** [configure-target-libgfortran
* Andrew Pinski <[EMAIL PROTECTED]> [2007-04-25 18:11]:
> So I don't think that is the issue. Can you look into config.log and
> make sure that the test is not emitting warnings. It is a link time
> test too.
In powerpc-linux-gnu/libgomp config.log shows undefined references
and config.h undefin
On 4/23/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
Since the change listed below, bootstrap on powerpc is broken when you
configure for both powerpc-linux and powerpc64-linux:
2007-04-04 Jakub Jelinek <[EMAIL PROTECTED]>
* libgomp.h (gomp_cpu_affinity, gomp_cpu_affinity_len): New
[resend]
On 3/29/07, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> I've attached a patch that should fix it (it
> just reverts the oprintf() changes, which were not really necessary, I
> was just trying to be more efficient).
Thanks, that fixes it for me on i386-pc-mingw32.
committed.
1 - 100 of 184 matches
Mail list logo
