[Since this gcc problem affects gdb, I'm sending this to both lists]
[Warning, long mail. But the actual description isn't that long, just the
testcases are.]
Hi,
a specific test in the GDB testsuite (namespace.exp) contains tests
on variables within anonymous namespaces. When compiling the t
Is there a PR existing for multilib build failures
of the form...
configure: error: `CXX' has changed since the previous run
...as described (and patch proposed) in...
http://sourceware.org/ml/newlib/2007/msg00425.html?
I am currently testing that patch with gcc trunk to see if
it eliminates
On 25 May 2007 13:03, Jack Howarth wrote:
>Is there a PR existing for multilib build failures
> of the form...
>
> configure: error: `CXX' has changed since the previous run
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=
allwordssubstr&short_desc=&known_to_fai
On Fri, May 25, 2007 at 02:00:35PM +0200, Corinna Vinschen wrote:
> IMHO, this is a bug in g++. The mangled name in DW_AT_MIPS_linkage_name
> is required so that GDB can correctly recognize mangled c++ symbols.
Yes, I think so. Keep in mind that, in turn, the dependency on
DW_AT_MIPS_linkage_na
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
> We need a configure time option to link statically against GMP and
> MPFR even if dynamic versions of the libraries are available.
>
> I would argue that static linking should be the default, since that is
> the least surprising o
[EMAIL PROTECTED] wrote:
If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to some other system, or
simply
On 5/25/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
> We need a configure time option to link statically against GMP and
> MPFR even if dynamic versions of the libraries are available.
>
> I would argue that static linking sho
On 25 May 2007 15:10, Ian Lance Taylor wrote:
> I would argue that static linking should be the default, since that is
> the least surprising option. People who understand the issues can
> enable dynamic linking.
And besides, wasn't it the case that one of the main points in defence of
addi
I just noticed a problem with our use of GMP and MPFR. If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to
> It's no different than any other library used by any other program.
> I wouldn't object to configure support to request static gmp/mpfr for
> developer convenience, but GCC is a perfectly normal dynamically
> linked program and should behave like one IMO.
How a compiler can be "a perfectly norma
On Fri, May 25, 2007 at 04:33:56PM +0200, Eric Botcazou wrote:
> > It's no different than any other library used by any other program.
> > I wouldn't object to configure support to request static gmp/mpfr for
> > developer convenience, but GCC is a perfectly normal dynamically
> > linked program an
On 25 May 2007 15:34, Eric Botcazou wrote:
>> It's no different than any other library used by any other program.
>> I wouldn't object to configure support to request static gmp/mpfr for
>> developer convenience, but GCC is a perfectly normal dynamically
>> linked program and should behave like on
Tim Prince <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > If you
> > carefully install the appropriate versions of GMP and MPFR on one
> > machine in the normal way, and build gcc on that machine,
> > cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
> > libmpfr.so. If
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
> I just noticed a problem with our use of GMP and MPFR. If you
> carefully install the appropriate versions of GMP and MPFR on one
> machine in the normal way, and build gcc on that machine,
> cc1/cc1plus/etc. wind up dynamically l
Dave Korn wrote:
On 25 May 2007 15:34, Eric Botcazou wrote:
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave
But I don't think that's enough, with the current loop it would strip the
subreg of a multiword subreg and there is some logic in df_ref_record,
which wouldn't see it. An alternative might be:
while (GET_CODE (dst) == STRICT_LOW_PART
|| GET_CODE (dst) == ZERO_EXTRACT)
{
f
On 25 May 2007 07:52:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Tim Prince <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > If you
> > carefully install the appropriate versions of GMP and MPFR on one
> > machine in the normal way, and build gcc on that machine,
> > cc1/cc1p
On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
> > I honestly don't know how to answer this question. Bootstrapping is an
> > unrelated problem, and the compiler is not a vital runtime component
> > of the system, so its dependencies do not need to be exceptionally
> > robust in th
> I honestly don't know how to answer this question. Bootstrapping is an
> unrelated problem, and the compiler is not a vital runtime component
> of the system, so its dependencies do not need to be exceptionally
> robust in the way that glibc's or even libstdc++'s do.
A compiler is a "second ord
> Bootstrapping GCC on a system is something that would be solved by
> placing GMP and MPFR in the build tree (as has been proposed), and once
> they are built as part of the usual bootstrap, it is irrelevant whether
> they are linked statically or dynamically. On the other hand, when one
> is dis
On Fri, 25 May 2007, Daniel Jacobowitz wrote:
> On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
> > > I honestly don't know how to answer this question. Bootstrapping is an
> > > unrelated problem, and the compiler is not a vital runtime component
> > > of the system, so its depend
On Fri, 25 May 2007, Dave Korn wrote:
> On 25 May 2007 15:34, Eric Botcazou wrote:
>
> Yes, hasn't this been one of the design goals of gcc for as long as any of
> us can remember? It wants to be able to bootstrap the GNU world on non-free
> systems from scratch and part of that is not requirin
Hi,
about two weeks ago I started submitting patches for C++ compatibility.
Unfortunately reviewing as been, ahem, a bit slow. Probably because
nobody cares about C++ compatibility. As I have only send 4% of the
total patch so far, the current acceptance rate (as in 0 patches in 2
weeks) bothers m
Back in 2006 I added a mechanism for defining machine-specific
constraints in the MD file rather than with C macros. This mechanism
offers several advantages over the old way of doing it, but until all
ports are converted, we can't actually implement some of those -- most
important, perhaps, is th
On 25/05/07, Thomas Neumann <[EMAIL PROTECTED]> wrote:
Hi,
about two weeks ago I started submitting patches for C++ compatibility.
Unfortunately reviewing as been, ahem, a bit slow. Probably because
nobody cares about C++ compatibility. As I have only send 4% of the
total patch so far, the curre
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for fixing on a release branch).
Thomas
Thomas Koenig wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for fixing on a release branch).
Well I
On 5/25/07, Thomas Koenig <[EMAIL PROTECTED]> wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for fix
> That just means that it's an application you care about. And now an
> upgrade of MPFR which fixes bugs will require you to rebuild the
> compiler.
Exactly. By design. What goes in the system compiler should be closely
scrutinized.
--
Eric Botcazou
Richard Guenther wrote:
On 5/25/07, Thomas Koenig <[EMAIL PROTECTED]> wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even s
> I don't personally have time to convert all ports, and it is better if
> people who know each individual backend and have access to hardware
> do the conversions, anyway. So I'd like to invite port maintainers to
> convert their ports in this development cycle. I see that many of
> the more p
On Friday 25 May 2007, Thomas Koenig wrote:
> What about a keyword for bugs that
>
> - generate wrong code
> - affect a standard-conforming program
> - are silent (no error message)
We already have one: "wrong-code"
1 and 3 mutually exclusive. ie. if we generate an error, then by definition we
d
Paul Brook wrote:
2 is a IMHO fairly academic distinction. We either care about code working
(and support no-conforming code as an extension), or we decide that we're ok
with that particular code being broken.
That's a better way to express the concern I had. I would not get
excited about som
On Fri, 2007-05-25 at 22:12 +0100, Paul Brook wrote:
> On Friday 25 May 2007, Thomas Koenig wrote:
> > What about a keyword for bugs that
> >
> > - generate wrong code
> > - affect a standard-conforming program
> > - are silent (no error message)
>
> We already have one: "wrong-code"
>
> 1 and 3
On Fri, May 25, 2007 at 02:04:16PM -0700, David Daney wrote:
> Richard Guenther wrote:
> >On 5/25/07, Thomas Koenig <[EMAIL PROTECTED]> wrote:
> >>What about a keyword for bugs that
> >>
> >>- generate wrong code
> >>- affect a standard-conforming program
> >>- are silent (no error message)
> >>
>
Hi,
as of revision 125076, tree-vect-transform.c contains the following code
in line 2010:
enum tree_code code, code1 = CODE_FOR_nothing, code2 = CODE_FOR_nothing;
This most likely wrong, CODE_FOR_nothing is an insn_code, not a
tree_code. Unfortunately there is no obvious fix (at least not obvio
Snapshot gcc-4.3-20070525 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070525/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Now!!
You can upload up to 500 MB !
Key features of fileWind.net:
- Free and no need to register to use.
- Easy to use, upload file, receive link, share.
- Files up to 500MB can be uploaded, can split files if too large.
- Unlimited storage, upload as many files as you want.
- Unlimited download
[EMAIL PROTECTED] wrote:
However there are two existing options in the mean time:
One is build/install gmp/mpfr yourself and specify --disable-shared to
both. Then use --with-mpfr= to specify using them instead of the system's
shared versions.
The second is to drop gmp/mpfr into the top leve
On May 25, 2007, at 2:10 PM, Eric Botcazou wrote:
I don't personally have time to convert all ports, and it is
better if
people who know each individual backend and have access to hardware
do the conversions, anyway. So I'd like to invite port
maintainers to
convert their ports in this d
40 matches
Mail list logo
