-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent wrote:
> Ranjit Mathew wrote:
>
>> I just noticed that even with "--disable-static --enable-static",
>
> Do you mean --disable-static --enable-shared?
Yes, sorry for the silly typo.
>> a Linux-to-MinGW cross compiler (mainline) sti
Ranjit Mathew wrote:
> I just noticed that even with "--disable-static --enable-static",
Do you mean --disable-static --enable-shared?
> a Linux-to-MinGW cross compiler (mainline) still created static
> libraries for the C++ and Java runtimes. Is this by design or is it
> a bug? From the point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I just noticed that even with "--disable-static --enable-static",
a Linux-to-MinGW cross compiler (mainline) still created static
libraries for the C++ and Java runtimes. Is this by design or is it
a bug? From the point of view of creating execu
Daniel Berlin <[EMAIL PROTECTED]> writes:
> It can also tell you who to copy on a ping email to make sure it
> actually goes to a maintainer.
> the interface is under construction, but "okay" for casual use.
> http://www.dberlin.org/patches/patches/maintainer_list/745 would be the
> one for this p
>
> IMHO this PR is a striking example of the *major* problems we have been
> having
> in the patch reviewing department for quite some time.
I don't disagree in this case.
Not only was this patch submitted in march and not reviewed, it was even
pinged on march 29th by someone *else*.
http
Any suggestions? Does the -isysroot compiler flag fix this sort of
issue? It does not seem to be used in the gcc build.
I'd expect it might. Run with -v and see if isysroot is given to
ld. If not, add -Wl,-isysroot=... to pass it down to ld. In later
compilers, we do this automagically
On 14/06/2006, at 5:15 AM, Mike Stump wrote:
None of this is a problem on MacOS X Intel. The cross-compilers
build without problems on an Intel Mac.
Well, apparently one solution is to fatten your system.
My attempts to do that just resulted in a system that would not boot :-(
Fortunately,
On Tue, Jun 13, 2006 at 11:39:25AM -0700, Mike Stump wrote:
> On Jun 13, 2006, at 2:02 AM, Roberto COSTA wrote:
> >In the meantime, I hope this doesn't prevent requesting a
> >development branch.
>
> I too think the SC should decide this issue. They are there for
> guidance, and on this issue
On Jun 13, 2006, at 1:21 AM, Bill Northcott wrote:
I am trying to build a universal APPLE gcc on a MacOS PPC system,
because I want to tweak it to add a couple extra features.
The assumption is incorrect because, MacOS PPC systems do not have
i386 code in their system libraries, only ppc and
On Jun 13, 2006, at 2:02 AM, Roberto COSTA wrote:
In the meantime, I hope this doesn't prevent requesting a
development branch.
I too think the SC should decide this issue. They are there for
guidance, and on this issue, I think that is what we need.
I don't think this prevents anyone fro
But right now what is given in the bug report is hard to reproduce as there is
no source
Right. I added a short snippet that reproduces the problem.
-BenRI
Hi!
On Fri, Jun 09, 2006 at 07:30:25PM +0200, Tim Janik wrote:
> On Fri, 9 Jun 2006, Kaveh R. Ghazi wrote:
> >> void print_string_array (const char *array_name,
> >> const char *string, ...) __attribute__
> >> ((__sentinel__));
>
>
> Ian Lance Taylor wrote:
> > Benjamin Redelings <[EMAIL PROTECTED]> writes:
> >
> >
> >> substitution.o:(.data+0x0): multiple definition of
> >> `_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
> >>
> >
> > I can't make sense of that as a mangled name. It has template
Ian Lance Taylor wrote:
Benjamin Redelings <[EMAIL PROTECTED]> writes:
substitution.o:(.data+0x0): multiple definition of
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
I can't make sense of that as a mangled name. It has template
parameter references but no templa
Andrew Haley wrote:
> Roberto COSTA writes:
> >
> > By the way, from the previous messages, I understand that the
> > inclusion of a CIL back-end into gcc cannot be taken as granted
> > until the issue is discussed and an approval is obtained.
>
> Right. And I wouldn't hold my breath waiting
On Tue, Jun 13, 2006 at 08:35:17AM -0700, Ian Lance Taylor wrote:
> Well, your libstdc++ was configured for a system which supports TLS
> (Thread Local Storage). That causes it to call __tls_get_addr in some
> cases. And you are explicitly linking against -lsupc++, which is an
> archive, not a sh
> However, the audit trail of the PR seems to say that now
> -fkeep-inline-functions is sort of implied by -O0; I can build
> insn-conditions.md with "-O0 -fkeep-inline-functions" so I'm not
> affected by the PR.
Comment #36 seems to say that we're back to the initial state.
--
Eric Botcazou
"yang xiaoxin" <[EMAIL PROTECTED]> writes:
> Building project store
> =
> /usr/src/rpm/BUILD/OOB680_m5/store/source
> -
> /usr/src/rpm/BUILD/OOB680_m5/store/util
> --
> Making: ../unxlngi6.pro/lib/libstore.so.3
> g++ -Wl,-z,combreloc -Wl,-z,defs
Roberto COSTA wrote:
> Ori Bernstein wrote:
> >On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <[EMAIL PROTECTED]>
> >said:
> >
> >
> >>Hello,
> >>
> >>I'm working for an R&D organization of STMicroelectronics. Within our
> >>team we have decided to write a gcc back-end that produces CIL binar
Eric Botcazou wrote:
I didn't understand the purpose of:
(build/gencondmd.o): Filter out -fkeep-inline-functions.
Read the comment?
It can help indeed.
However, the audit trail of the PR seems to say that now
-fkeep-inline-functions is sort of implied by -O0; I can build
insn-c
On Tue, Jun 13, 2006 at 12:01:39PM +0100, Andrew Haley wrote:
>
> All you've got here is an inline asm version of
>
> inline void longcpy(long* _dst, long* _src, unsigned _numwords)
> {
> __builtin_memcpy (_dst, _src, _numwords * sizeof (long));
> }
>
> which gcc will optimize if it can.
>
[EMAIL PROTECTED] writes:
> On Tue, Jun 13, 2006 at 10:37:29AM +, [EMAIL PROTECTED] wrote:
> > On Mon, Jun 12, 2006 at 04:59:04PM -0700, Ian Lance Taylor wrote:
> > >
> > > Probably better to say that these are read-write operands, using the
> > > '+' constraint.
> > >
> > > > Now ever
On Tue, Jun 13, 2006 at 10:37:29AM +, [EMAIL PROTECTED] wrote:
> On Mon, Jun 12, 2006 at 04:59:04PM -0700, Ian Lance Taylor wrote:
> >
> > Probably better to say that these are read-write operands, using the
> > '+' constraint.
> >
> > > Now everything works fine at -O3. However, I really don
On Mon, Jun 12, 2006 at 04:59:04PM -0700, Ian Lance Taylor wrote:
>
> Probably better to say that these are read-write operands, using the
> '+' constraint.
>
> > Now everything works fine at -O3. However, I really don't understand
> > the '&' early clobber constraint modifer. What use is it?
>
Grigory Zagorodnev wrote:
Hi!
Build of mainline GCC on ia64-redhat-linux failed since Thu Jun 8
16:23:09 UTC 2006 (revision 114488). Last successfully built revision is
114468.
I wonder if somebody sees the same.
...
- Grigory
This was fixed in revision 114604.
--
Maxim
Hi!
Build of mainline GCC on ia64-redhat-linux failed since Thu Jun 8
16:23:09 UTC 2006 (revision 114488). Last successfully built revision is
114468.
I wonder if somebody sees the same.
make[4]: Entering directory `/home/user/gcc-42/bld/gcc'
/home/user/gcc-42/bld/./gcc/xgcc -B/home/user/gcc
Roberto COSTA writes:
>
> By the way, from the previous messages, I understand that the
> inclusion of a CIL back-end into gcc cannot be taken as granted
> until the issue is discussed and an approval is obtained.
Right. And I wouldn't hold my breath waiting.
> In the meantime, I hope this
Ori Bernstein wrote:
On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <[EMAIL PROTECTED]> said:
Hello,
I'm working for an R&D organization of STMicroelectronics. Within our
team we have decided to write a gcc back-end that produces CIL binaries
(compliant with ECMA specification, see
htt
On 6/13/06, Gavin Band <[EMAIL PROTECTED]> wrote:
Hello,
I hope this is the right place for this sort of question, which concerns
the behaviour of gcc (versions 3.4.4 and 4.1.1) and template
specialisations.
I have some code split into three files header.hpp, specialisation.cpp,
and main.cpp, gi
Hello,
I hope this is the right place for this sort of question, which concerns
the behaviour of gcc (versions 3.4.4 and 4.1.1) and template
specialisations.
I have some code split into three files header.hpp, specialisation.cpp,
and main.cpp, given below. A class having a template member functio
> I didn't understand the purpose of:
>
> (build/gencondmd.o): Filter out -fkeep-inline-functions.
Read the comment?
--
Eric Botcazou
I am trying to build a universal APPLE gcc on a MacOS PPC system,
because I want to tweak it to add a couple extra features.
The build fails as already described here:
http://www.cocoabuilder.com/archive/message/cocoa/2005/6/24/139961
The problem seems to be around line 1626 of gcc/configure.
Eric Botcazou wrote:
Thanks for chiming in this discussion. You've clearly given a good deal
of thought to the problem, and if you have suggestions I'm all ears.
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00297.html
Cool. Mark, this is very similar to my patch, but better. :-)
I didn
> Thanks for chiming in this discussion. You've clearly given a good deal
> of thought to the problem, and if you have suggestions I'm all ears.
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00297.html
--
Eric Botcazou
Eric Botcazou wrote:
An untested patch to do so is attached. You can try it and, if it
fails, there is also Rainer Orth's patch in comment #14 of the PR.
Sure, but read the date of the comment. :-)
Yes, OTOH it is the patch that I like the most...
Thanks for chiming in this discussion
> An untested patch to do so is attached. You can try it and, if it
> fails, there is also Rainer Orth's patch in comment #14 of the PR.
Sure, but read the date of the comment. :-)
I'm really wondering what the "Patch URL" field of the PR is for...
IMHO this PR is a striking example of the *maj
I think that, after Zack's change, the generator programs that include
rtl.h should be linked with build/vec.o. That may not be necessary when
optimizing, but it would avoid this problem. Do you agree?
Well, if it fixes the bug, yes: I prefer to fix this in the makefile
than with #ifdef GE
The behavior prior to the top-level bootstrap changes that I and
others repeatedly have mentioned in email and IRC: if I type "make cc1" in
the gcc subdirectory, the build should be invoked with the appropriate
options from the current build stage. In other words, if I have a
completely
38 matches
Mail list logo
