On Jun 11 2024, Florian Weimer via Gcc wrote:
> I suspect that io_quotes_def and io_quotes_use in particular often get
> applied spuriously.
The message "Applying foo" does not mean that the header is actually
changed. That only happens if you see "Fixed: foo.h".
--
Andreas Schwab, SUSE Labs,
* Richard Biener via Gcc:
> But are they still needed? Often headers already contain
> alternatives for standard conforming compilers or GCC can now
> deal with the contents.
I suspect that io_quotes_def and io_quotes_use in particular often get
applied spuriously.
Thanks,
Florian
On Tue, 4 Jun 2024, 21:42 FX Coudert via Gcc, wrote:
> Hi,
>
> I am trying to reduce the number of unneeded fixincludes that are used on
> darwin (because fixincluded headers make it impossible to change SDK once
> the compiler is built, which is common practice in the macOS wor
and default to on.
> >
> > It would be great if we could measure what fixincludes are still needed,
> > on which targets. Could we possibly modify contrib/test_summary to list the
> > fixincluded headers? How would people feel about that?
> >
> > Out of 273 fixes,
> Laugh or cry.
Wow. But how does any other compiler deal with them?
I’ve pushed the change as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66d6b1861ec57ba29540a5fa7854df3978ba5409
Please let me know if you see any issue in the next tests.
FX
On Thu, Jun 6, 2024 at 6:22 AM FX Coudert via Gcc wrote:
> Hi,
>
> > I usually just install with install-no-fixedincludes, but really this
> > should probably be a configure option and default to on.
>
> It would be great if we could measure what fixincludes are still ne
> On 6 Jun 2024, at 12:41, Sam James via Gcc wrote:
>
> Andi Kleen via Gcc writes:
>
>> FX Coudert via Gcc writes:
>>
>>> I am trying to reduce the number of unneeded fixincludes that are used
>>> on darwin (because fixincluded headers mak
Andi Kleen via Gcc writes:
> FX Coudert via Gcc writes:
>
>> Hi,
>>
>> I am trying to reduce the number of unneeded fixincludes that are used
>> on darwin (because fixincluded headers make it impossible to change
>> SDK once the compiler is built, which is c
Hi,
> I usually just install with install-no-fixedincludes, but really this
> should probably be a configure option and default to on.
It would be great if we could measure what fixincludes are still needed, on
which targets. Could we possibly modify contrib/test_summary to li
FX Coudert via Gcc writes:
> Hi,
>
> I am trying to reduce the number of unneeded fixincludes that are used
> on darwin (because fixincluded headers make it impossible to change
> SDK once the compiler is built, which is common practice in the macOS
> world, and quite usefu
Hi,
I am trying to reduce the number of unneeded fixincludes that are used on
darwin (because fixincluded headers make it impossible to change SDK once the
compiler is built, which is common practice in the macOS world, and quite
useful).
There are currently two generic (not darwin-specific
On Wed, 26 May 2021, Richard Earnshaw via Gcc wrote:
>> ../../git/gcc/fixincludes/fixtests.c: In function ‘run_test’:
>> ../../git/gcc/fixincludes/fixtests.c:155:1: internal compiler error:
>> in operator[], at vec.h:890
>> 155 | }
>> | ^
> Same failure on
On Mai 26 2021, Uros Bizjak via Gcc wrote:
> The build currently fails to build for me on x86_64 in fixincludes:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571274.html
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A
On 26/05/2021 13:22, Uros Bizjak via Gcc wrote:
The build currently fails to build for me on x86_64 in fixincludes:
/home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux
The build currently fails to build for me on x86_64 in fixincludes:
/home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys
T-Bird snafu resend:
On 06/05/17 14:52, Bruce Korb wrote:
> On 06/01/17 07:24, Douglas B Rupp wrote:
>>
>> This is a reproducer for a problem we have with fixincludes on
>> vxworks6.6. The desired output is
>> FOO= 1
>>
>> The problem is the rules for
On 06/01/17 07:24, Douglas B Rupp wrote:
>
> This is a reproducer for a problem we have with fixincludes on
> vxworks6.6. The desired output is
> FOO= 1
>
> The problem is the rules for handling headers enclosed in quotes can
> cause gcc to #include the original header n
This is a reproducer for a problem we have with fixincludes on
vxworks6.6. The desired output is
FOO= 1
The problem is the rules for handling headers enclosed in quotes can
cause gcc to #include the original header not the patched header.
It seems like a problem that could theoretically
On 10/25/14 10:40, Bruce Korb wrote:
On 10/21/14 02:30, Uros Bizjak wrote:
2014-10-21 Uros Bizjak
* inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
* fixincl.x: Regenerate.
Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.
OK for mainline?
I
On 10/21/14 02:30, Uros Bizjak wrote:
2014-10-21 Uros Bizjak
* inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
* fixincl.x: Regenerate.
Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.
OK for mainline?
On Tue, Oct 21, 2014 at 11:30:49AM +0200, Uros Bizjak wrote:
> At the end of the day, adding pthread.h to glibc_c99_inline_4 fix
> fixes the bootstrap. The fix applies __attribute__((__gnu_inline__))
> to the declaration:
>
> extern __inline __attribute__ ((__gnu_inline__)) void
> __pthread_cleanu
lect2: error: ld returned 1 exit status
>> > gmake[5]: *** [libgcc_s.so] Error 1
>> >
>> > $ ld --version
>> > GNU ld version 2.17.50.0.6-26.el5 20061020
>>
>> It looks like a switch-to-c11 fallout. Older glibc versions have
>> issues with c99 (and c
for android-L. Do you have example? We can fix up bionic headers for
> all levels in NDK to make fixincluded consistent if not gone
> completely
>
> On Wed, Jul 16, 2014 at 8:08 PM, Alexander Ivchenko
> wrote:
>> Hi, I have a question about sysroot and fixincludes.
&g
Jul 16, 2014 at 8:08 PM, Alexander Ivchenko wrote:
> Hi, I have a question about sysroot and fixincludes.
>
> On Android there are different API levels (like android-9, android-10
> etc) that match different versions of OS. Gcc from NDK is configured
> using sysroot for android-
Hi, I have a question about sysroot and fixincludes.
On Android there are different API levels (like android-9, android-10
etc) that match different versions of OS. Gcc from NDK is configured
using sysroot for android-9 and the convenient way for compiling for,
say, android-19 was by providing
Does anyone know if it is possible to have the toplevel configure.ac set...
--with-sysroot="`xcrun --show-sdk-path`"
for darwin13 or later? In particular, I am confused by the fact that the
toplevel
configure.ac doesn't define that particular configure option and just passes it
down to the lo
On Thu, Jul 04, 2013 at 10:41:45AM -0700, Bruce Korb wrote:
> On 07/04/13 09:40, Jack Howarth wrote:
>> Currently I am forced to manually patch fixincludes/fixinc.in to have the
>> DIR passed to
>> --with-sysroot honored during the bootstrap. Thanks in advance for any help
On Thu, Jul 04, 2013 at 10:41:45AM -0700, Bruce Korb wrote:
> On 07/04/13 09:40, Jack Howarth wrote:
>> Currently I am forced to manually patch fixincludes/fixinc.in to have the
>> DIR passed to
>> --with-sysroot honored during the bootstrap. Thanks in advance for any help
On 07/04/13 09:40, Jack Howarth wrote:
Currently I am forced to manually patch fixincludes/fixinc.in to have the DIR
passed to
--with-sysroot honored during the bootstrap. Thanks in advance for any help in
getting
this oversight in fixincludes fixed for gcc 4.9.
Jack
I saw the
Bruce,
While bootstrapping darwin without the SDK (aka /usr/include) being present
in /,
I discovered the latent defect that fixincludes/fixinc.in doesn't honor the use
of the
--with-sysroot configure option and blindly uses the headers in /usr/include.
The code in fixincludes needs
On Sun, Jun 3, 2012 at 1:45 AM, Jonathan Wakely wrote:
> On 3 June 2012 01:30, Jeremy Huntwork wrote:
>>
>> After reading up further, it appears that the possibility exists that the
>> script may 'fix' things in the libc headers that we don't want or need
>> 'fixed'. I'm trying to ascertain what t
at gcc always supplies an internal limits.h which usually
then directly includes the system limits.h regardless of whether the
fixincludes script is used or not.
JH
On 3 June 2012 01:30, Jeremy Huntwork wrote:
>
> After reading up further, it appears that the possibility exists that the
> script may 'fix' things in the libc headers that we don't want or need
> 'fixed'. I'm trying to ascertain what things the script in particular is
> 'fixing' and which way is
t; need 'fixed'. I'm trying to ascertain what things the script in
> particular is 'fixing' and which way is more technically sound in our
> build scenario.
In my experience, bugs in fixincludes are very rare. Every fix that is applied
is documented in the sources.
--
Eric Botcazou
On 6/2/12 5:34 PM, Eric Botcazou wrote:
What are you after, exactly? Even on modern OSes, there might be glitches or
small incompatibilities that woud need to be fixed in order for GCC to work
properly, and fixincludes is the tried and proven tool to do that. It is
designed to modify only what
27;t
> be altered?
What are you after, exactly? Even on modern OSes, there might be glitches or
small incompatibilities that woud need to be fixed in order for GCC to work
properly, and fixincludes is the tried and proven tool to do that. It is
designed to modify only what needs to be modified
On May 28, 2012, at 7:25 PM, Jonathan Wakely wrote:
> The "upstream packages" might be a third-party OS vendor who supply
> their own compiler and have no interest in supporting GCC. Even if the
> OS system headers get changed, that doesn't help users who have the
> unchanged version (e.g. someon
On 29 May 2012 00:19, Jeremy Huntwork wrote:
> Hello,
>
> I'm endeavoring to understand the history and purpose of the fixincludes
> script. The README-fixinc states that the purpose is to fix
> ANSI-incompatible headers which 'many vendors supply'. Is this really
Hello,
I'm endeavoring to understand the history and purpose of the fixincludes
script. The README-fixinc states that the purpose is to fix
ANSI-incompatible headers which 'many vendors supply'. Is this really
still the case? Certainly by now this is very rare and corner cases
On Wed, 8 Jun 2011, Andreas Schwab wrote:
Basile Starynkevitch writes:
And I also believe that the minuscule patch I am proposing in
http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
should work on your system too. Could you try it please?
That's not the point. The point is, if you patch, yo
On Wed, 08 Jun 2011 21:54:56 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > And I also believe that the minuscule patch I am proposing in
> > http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
> > should work on your system too. Could you try it please?
>
> That's not the point.
Basile Starynkevitch writes:
> And I also believe that the minuscule patch I am proposing in
> http://gcc.gnu.org/ml/gcc/2011-06/msg00081.html
> should work on your system too. Could you try it please?
That's not the point. The point is, if you patch, you should do it
right.
Andreas.
--
Andr
On Wed, 08 Jun 2011 20:52:51 +0200
Andreas Schwab wrote:
> Basile Starynkevitch writes:
>
> > You see, not Ver. string in it.
>
> $ autogen -v
> autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.1
I might believe that could be more a issue in autogen than in GCC.
And I also
Basile Starynkevitch writes:
> You see, not Ver. string in it.
$ autogen -v
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.1
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something c
t; test.
> >
> > The following patch corrects that.
> >
> > Index: fixincludes/genfixes
> > ===========
> > --- fixincludes/genfixes(revision 174734)
> > +++ fixincludes/genfixes(working copy)
> &g
Basile Starynkevitch writes:
> Hello
>
> With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
> perhaps /Experimental) the genfixes script fail, because of the version
> test.
>
> The following patch corrects that.
>
>
Hello
With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
perhaps /Experimental) the genfixes script fail, because of the version
test.
The following patch corrects that.
Index: fixincludes/genfixes
Jay K writes:
> Ok if I do both or the emails are just annoying?
As far as I'm concerned, it's fine to do both.
> I find that bugs are often ignored just as well (but not lost/forgotten,
> granted. :) )
Agreed on both counts.
Ian
Ok if I do both or the emails are just annoying?
I find that bugs are often ignored just as well (but not lost/forgotten,
granted. :) )
Thanks,
- Jay
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: -disable-fixincludes does
Jay K writes:
> -disable-libgcc and/or -disable-fixincludes are useful, depending on your
> goal.
>
> Like if you just want to compile C to assembly or object files.
>
>
> It fails, but only after doing what I want anyway.
>
> make[2]: *** No rule to make ta
-disable-libgcc and/or -disable-fixincludes are useful, depending on your goal.
Like if you just want to compile C to assembly or object files.
It fails, but only after doing what I want anyway.
make[2]: *** No rule to make target
`../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh
needed to use
fixincludes when we flipped the meaning of "extern inline" from the
GNU89 meaning to the C99 meaning when running in C99 mode.)
Ian
Richard Guenther wrote:
On Sat, Jan 23, 2010 at 5:43 PM, Franz Fehringer wrote:
but an OS update could lead to updated C runtime headers?
Yes.
There is still one point I don't understand about fixincludes.
Why is it still useful on recent GNU/Linux systems?
From what I under
On Sat, Jan 23, 2010 at 5:43 PM, Franz Fehringer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> understood.
> but an OS update could lead to updated C runtime headers?
Yes.
Richard.
t;
>> Hi all,
>>
>> I have two hopefully not too dull questions about the gcc fixincludes
>> mechanism:
>> 1) When after the initial fixinclude run (parts of) new software is
>> installed into /usr/include, the fixincludes run has to be repeated (at
>&g
On Sat, Jan 23, 2010 at 5:34 PM, Franz Fehringer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> I have two hopefully not too dull questions about the gcc fixincludes
> mechanism:
> 1) When after the initial fixinclude run (parts of) new software
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I have two hopefully not too dull questions about the gcc fixincludes
mechanism:
1) When after the initial fixinclude run (parts of) new software is
installed into /usr/include, the fixincludes run has to be repeated (at
least in principle
On Wed, May 20, 2009 at 2:47 PM, Steve Ellcey wrote:
> I have a question about the use of sed by fixincl and mkheaders
> and a change that was made between 4.3.* and 4.4.0.
> After this patch, the sed used when building GCC is saved in a config
> file and that path to sed is used when you run mkh
I have a question about the use of sed by fixincl and mkheaders
and a change that was made between 4.3.* and 4.4.0.
It involves this patch:
2008-09-06 Bruce Korb
* fixincl.tpl (sed): make the program executable configurable.
Some platforms have some rather oddball defaults.
Hi!
I have made some progress with your help. I have fixed the sed part:
(1) there were missing 's' in the scripts, first I did not noticed it,
then I did not know if I was supposed to povide it;
(2) I have replaced the [ \t]+ by [ \t][ \t]*
to get:
--- ../_gcc_clean/fixincludes/in
\n";
This is one half of the testcase for the fix: text taken from the broken
system header.
The other half of the testcase for the fix is updates to
tests/base/stdint.h to show what the output should be for that input from
the broken system header. You don't include that diff. Typically you
generate it by running the fixincludes testsuite and copying the output
header it generates into your source tree after verifying that fixincludes
did indeed make the desired changes to the test text.
--
Joseph S. Myers
jos...@codesourcery.com
>> sed does not have +.
>
> Thanks for the hint. Apparently GNU sed version 4.1.5 has it, provided you
> use -r,
It also has \+ without -r, but neither -r nor \+ are portable.
Paolo
Paolo,
> sed does not have +.
Thanks for the hint. Apparently GNU sed version 4.1.5 has it, provided you use
-r,
but I was wondering what to do since I did not see it in fixincl.x.
So I will use [ \t][ \t]*.
Dominique
Dominique Dhumieres wrote:
> Dave,
>
> I have looked more closely to the sed part and it is probably incorrect,
> i.e. doing nothing. I'll coninue to experiment, but if you or someone else
> have idea, I'll be glad to use it.
sed does not have +. You need to use [ \t][ \t]* assuming that autoge
Dave,
I have looked more closely to the sed part and it is probably incorrect,
i.e. doing nothing. I'll coninue to experiment, but if you or someone else
have idea, I'll be glad to use it.
Thanks,
Dominique
Dominique Dhumieres wrote:
> I have reported the error in pr445#15 and explained in comment #6:
PR448, to be precise. I see Joseph is back from his AFK and has added
comment#16.
> /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function
> 'test_ptr': /opt/gcc/gcc-4.5-work/gcc/te
Dave,
Thanks for the quick answer.
> I don't know what it's trying to tell you with the fixincludes FAIL. Did
> you verify manually if the fixes perhaps didn't match against the stdint.h you
> have on your release of the O/S?
AFAICT the patch looks fine, but I cannot
Dominique Dhumieres wrote:
> FX Coudert has sent me the following patch for fixincludes/inclhack.def:
[ snipped all but one representative line. ]
> +sed = "/#define[ \t]+INTPTR_MIN[\t]+INT64_MIN/#define INTPTR_MIN
> ((intptr_t) INT64_MIN)/";
> I have succeeded to
Hi,
FX Coudert has sent me the following patch for fixincludes/inclhack.def:
--- ../_gcc_clean/fixincludes/inclhack.def 2009-03-31 22:37:57.0
+0200
+++ fixincludes/inclhack.def2009-04-06 19:50:43.0 +0200
@@ -1023,6 +1023,35 @@
/*
+ * Fix stdint.h header on Darwin
>> Was it fixincludes or was it the mkheaders script ?
>>
>> and why ?
>
> Because system headers should not define something in the users namespace,
> certainly not a non-uglified three-letter name such as "sun".
>
> Consider
>
> #include
>
&
On Sat, Feb 7, 2009 at 7:27 PM, Dennis Clarke wrote:
>
> This is just a question. Hopefully someone can shed some light on what the
> fixincludes stage of "make install" does. I am making the assumption that
> the "make install" stage is where these headers get man
This is just a question. Hopefully someone can shed some light on what the
fixincludes stage of "make install" does. I am making the assumption that
the "make install" stage is where these headers get mangled or modified.
This is on Solaris 8 by the way.
Once make install ha
starting from build i686-pc-cygwin
build native
build host i686-pc-cygwin target sparc-sun-solaris2.10 -with-sysroot
and then host sparc-sun-solaris2.10 target sparc-sun-solaris2.10
installing with destdir = /usr/local/sparc-sun-solaris2.10/install
fixincludes took
d:\cygwin
end " Missing header fix: pthread.h"
Applies to {powerpc,i686}-apple-darwin8.
Is this relevant?
Iain
=
autogen -T /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/check.tpl /
Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/inclhack.def
/bin/sh ./check.sh /Volumes/UFSScratch/GCC
Hello!
On Mon, Dec 03, 2007 at 05:05:10PM -0800, Ian Lance Taylor wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> > > Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > > > Is this a GCC issue or should the glibc build syste
Thomas Schwinge <[EMAIL PROTECTED]> writes:
> Hello!
>
> On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> > Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > > Is this a GCC issue or should the glibc build system be adding a
> > > ``-isystem [GCC target]/4.3.0/include-fixed''?
>
Hello!
On Mon, Dec 03, 2007 at 03:18:42PM -0800, Ian Lance Taylor wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > Is this a GCC issue or should the glibc build system be adding a
> > ``-isystem [GCC target]/4.3.0/include-fixed''?
>
> The latter.
>
> http://sourceware.org/ml/libc-alpha/2
Thomas Schwinge <[EMAIL PROTECTED]> writes:
> Is this a GCC issue or should the glibc build system be adding a
> ``-isystem [GCC target]/4.3.0/include-fixed''?
The latter.
http://sourceware.org/ml/libc-alpha/2007-03/msg00017.html
Ian
Hello!
What is the reason for GCC (trunk version) installing the
header file as `PREFIX/lib/gcc/*/*/include-fixed/limits.h' instead of
putting it into `PREFIX/lib/gcc/*/*/include/', which is what
gcc-4_2-branch and earlier have been doing?
The leads to a problem as follows. You're about to boot
Hi,
I am compiling arm-elf-gcc using mingw on Windows XP through msys, and
although the C compiler compiles there is output near the end, which
includes a file error for fixincludes. The file doesn't exist after the
build.
...
sed: Couldn't open file C:\Temp\fxinc2;
FS error 2 (No
Paolo Bonzini wrote:
Am I correct in guessing that the "missing" lines in Makefile.def are
not currently needed? Or are they merely present in the GCC fixincludes
but missing in the fixincludes directories in some other trees that
share the top-level build files?
Yes, a patch th
Am I correct in guessing that the "missing" lines in Makefile.def are
not currently needed? Or are they merely present in the GCC fixincludes
but missing in the fixincludes directories in some other trees that
share the top-level build files?
Yes, a patch that removes the "
Why is it that Makefile.def includes:
// "missing" indicates that that module doesn't supply
// that recursive target in its Makefile.
[...]
host_modules= { module= fixincludes;
missing= info;
missing= dvi;
missing= pdf;
Hi all,
I spent the last couple of hours tracking down PR29867 through fixincludes.
Now, as the actual problem is identified, I lack the knowledge to fix it
appropriately. Could someone more involved with fixincludes comment on this?
Thanks.
The problem: fixes "glibc_c99_inline_1
This patch broke building GCC because Makefile indention was done with
spaces instead of a TAB.
Obvious fix commited, r115313. That will teach me how to think "oh
well that's a tiny patch I sent a month ago, I'll just copy it from
the mail archives instead of locating it on my disk".
Sorry.
--
c&view=rev&rev=115310
> Log:
> fixincludes:
> 2006-07-10 Laurynas Biveinis <[EMAIL PROTECTED]>
>
> PR bootstrap/20437
> * Makefile.in (configure, config.h.in): change into $(srcdir)
> before autoconf or autoheader call.
This patch broke building
On Mon, 2006-07-10 17:58:19 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: lauras
> Date: Mon Jul 10 17:58:18 2006
> New Revision: 115310
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115310
> Log:
> fixincludes:
> 2006-07-10
On Sat, 13 May 2006, Bernhard Fischer wrote:
> s/exercize/exercise/ in fixincludes/README
> Please apply.
>
> 2006-05-13 Bernhard Fischer <[EMAIL PROTECTED]>
>
> * README: Fix typo.
Please go ahead and commit this. (BTW, you do not need to Cc:
the gcc list on
Hi,
s/exercize/exercise/ in fixincludes/README
Please apply.
2006-05-13 Bernhard Fischer <[EMAIL PROTECTED]>
* README: Fix typo.
Index: gcc-4.2/fixincludes/README
===
--- gcc-4.2/fixincludes/README (revision
have to give us a hint which part failed him, for me to know
> just what went wrong.
It's not a generated file. Autogen is run during the fixincludes
testsuite.
--
Daniel Jacobowitz
CodeSourcery
Mike Stump wrote:
Hum, I'd say that contrib/gcc_update should be used, if it wasn't, and
that the make files should only have the dependencies if in maintainer
mode, and that maintainers should have autogen. Toon would have to
give us a hint which part failed him, for me to know just what
On Mar 10, 2006, at 7:15 PM, Andrew Pinski wrote:
On Mar 10, 2006, at 10:13 PM, Toon Moene wrote:
autogen -T ../../trunk/fixincludes/check.tpl ../../trunk/
fixincludes/inclhack.def
make[2]: autogen: Command not found
Maybe we should change this to be
autogen || true
so that we don&#
On Mar 10, 2006, at 10:13 PM, Toon Moene wrote:
autogen -T ../../trunk/fixincludes/check.tpl
../../trunk/fixincludes/inclhack.def
make[2]: autogen: Command not found
Maybe we should change this to be
autogen || true
so that we don't get that many complaints about this. Anyway
to be done for `check'.
make[2]: Leaving directory `/home/toon/compilers/obj-t/fastjar'
make[2]: Entering directory `/home/toon/compilers/obj-t/fixincludes'
autogen -T ../../trunk/fixincludes/check.tpl
../../trunk/fixincludes/inclhack.def
make[2]: autogen: Command not found
--
Toon Moene
Andreas Jaeger wrote:
Running make check in fixincludes on x86_64-gnu-linux I get the
following failure:
Just grepping for "_STRING_INCLUDED" it is easy to see the input rule in
inclhack.def that defines this transformation, and the output rule in
fixincl.x that actuall
Running make check in fixincludes on x86_64-gnu-linux I get the
following failure:
Fixed: Xm/Traversal.h
cmp: EOF on string.h
*** string.h2005-11-10 12:25:31.0 +0100
--- /cvs/gcc-svn/trunk/fixincludes/tests/base/string.h 2005-11-10
12:23:56.0 +0100
[EMAIL PROTECTED] wrote:
> 1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the
> building in "fixincludes" uses the gcc (with no PATH specification)
> instead of the xgcc build by the last stage. It may crash, it happens on
> my environment, because I've
Dear Sirs,
1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the
building in "fixincludes" uses the gcc (with no PATH specification)
instead of the xgcc build by the last stage. It may crash, it happens on
my environment, because I've migrated from Solaris 9 to S
I updated my local tree today and now every time I 'make
restage1', fixincludes are run again. Is this a bug, or do we
need to run fixincludes all the time?
To reproduce:
$ configure && make restage1
$
$ make restage1
Diego.
99 matches
Mail list logo
