On Wed, Mar 12, 2008 at 10:44:48PM +1100, Greg Schafer wrote:
> Currently, -B doesn't add the multilib search paths when processing
> startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in
> $prefix/lib/../lib64
>
> Most other calls to add_prefix
Hi,
Currently, -B doesn't add the multilib search paths when processing
startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in
$prefix/lib/../lib64
Most other calls to add_prefix() in gcc.c that refer to startfile_prefixes
do actually process the multilibs. Is there any good
On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote:
> Greg Schafer wrote:
> >Hi Carlos and Mark,
> >
> >Your "Relocated compiler should not look in $prefix" patch here:
> >
> >http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
> >
On Mon, Mar 03, 2008 at 08:11:30AM -0500, Hans-Peter Nilsson wrote:
> On Sun, 2 Mar 2008, Greg Schafer wrote:
> > Hi Carlos and Mark,
> >
> > Your "Relocated compiler should not look in $prefix" patch here:
> >
> > http://gcc.gnu.org/ml/gcc/2006-10/msg
On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote:
> Greg Schafer wrote:
> >Hi Carlos and Mark,
> >
> >Your "Relocated compiler should not look in $prefix" patch here:
> >
> >http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
> >
Hi Carlos and Mark,
Your "Relocated compiler should not look in $prefix" patch here:
http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
appears to have caused a regression in my GCC 4.3 testing.
In summary, there is a small window *during the GCC build itself* where GCC
does not pick up the correc
Richard Guenther wrote:
> On Feb 17, 2008 9:38 AM, Greg Schafer <[EMAIL PROTECTED]> wrote:
>> .stabn 68,0,91,.LM210-__get_cpuid_max
>> .LM210:
>> #APP
>> pushf{l|d}
>> pushf{l|d}
>> pop{l} %eax
>> mov{l} {%eax,
Hi,
driver-i386.s: Assembler messages:
driver-i386.s:2454: Error: invalid character '{' in mnemonic
driver-i386.s:2455: Error: invalid character '{' in mnemonic
driver-i386.s:2456: Error: invalid character '{' in mnemonic
driver-i386.s:2457: Error: invalid character '{' in mnemonic
driver-i386.s:2
Mark Mitchell wrote:
> I don't believe there's a serious problem with the concept, as long as
> "./configure; make; make install" for GMP DTRT. If you can do it for
> GCC, you can do it for a library it uses too.
Just another data point.
I tried building GMP on an i686-pc-linux-gnu Ubuntu sys
Mark Mitchell wrote:
> This will be the final patch for GCC 4.1.0. I plan to work through the
> release checklist tonight. As always, the official announcement will
> follow after the release has had time to make it to the mirrors.
Just a word of warning about this patch for unsuspecting travel
Mark Mitchell wrote:
> Please download, build, and test. Please use these tarballs, rather
> than the current SVN branch, so that we test packaging, and other
> similar issues.
Here it looks good so far on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01036.html
Regards
Gr
Hi
Sorry if this is the wrong address to contact.
This is a minor request for a minor libmudflap problem.
Could somebody with appropriate privilege please do me a favor and reopen
the following bugzilla PR?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
It seems the system won't let me do
On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:
> It looks like you forgot to check the crt*.o files for undefined
> references.
>
> If the gcc/glibc toolchain wasn't built the optimal way, it is possible
> for crtbegin.o to have register_frame_info and deregister_frame_info
> cal
Hi
This is just a headsup for any folks running 3.4.x testsuite under Linux
2.6.12 kernels (stock Linus).
I started seeing new PCH failures after upgrading to this kernel:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01069.html
The cause is due to inclusion of the address space randomizat
On Sun, May 15, 2005 at 01:54:03AM +0200, Ulrich Weigand wrote:
> It would appear the problem is this patch:
> 2005-05-12 Mark Mitchell <[EMAIL PROTECTED]>
>
> 2005-04-04 Mark Mitchell <[EMAIL PROTECTED]>
> * testsuite/Makefile.am (check-local): Remove.
> (curent_symbo
On Fri, May 13, 2005 at 03:44:59PM -0700, Mark Mitchell wrote:
> GCC 3.4.4 RC2 is now available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
>
> There are just a few changes from RC1 to fix critical problems people
> experienced with RC1.
>
> Please download, build, and test.
On Sun, Apr 10, 2005 at 03:05:17PM -0700, Mark Mitchell wrote:
> The first GCC 4.0 candidate is available from:
>
> /pub/gcc/prerelease-4.0.0-20050410/
My test results on i686-pc-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00812.html
All looks good except for the libmudflap f
On Fri, Mar 25, 2005 at 12:06:33PM +0100, Eric Botcazou wrote:
> What is wrong exactly? Why should 2 different build processes generate the
> same executable? Is there a (written) rule about this?
No, there is no written rule. However, some folks (like me) are concerned
with matters of binary
On Fri, Mar 25, 2005 at 08:46:12AM +0100, Eric Botcazou wrote:
> Isn't that always the case in general? With a 'make bootstrap' the compiler
> is built by itself whereas with a bare 'make' it is built by the installed
> compiler. So in general the final compilers are not identical.
Umm.. you'
Hi
There are occasions, especially when bootstrapping a whole new World where
one needs to build GCC multiple times, that you don't want to be
bootstrapping GCC on every invocation, only the first.
On x86 with GCC-4 and above, `make bootstrap' results in the compiler being
built with `BOOT_CFLAGS
On Wed, Mar 09, 2005 at 02:51:52PM -0800, Mark Mitchell wrote:
> As per previous announcements, please do not place a target milestone
> on bugs that are not part of the release criteria.
Hmm, see below.
> 4.0 Status
> ==
> In order to help us hit the April 15th target for GCC 4.0, plea
21 matches
Mail list logo
