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
[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
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
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
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
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)
> >>
>
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
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 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
> 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
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
> 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
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
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
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
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
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
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
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
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
> 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
> 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
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
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
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
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 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
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 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
> 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 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
[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 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
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
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 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
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
[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
40 matches
Mail list logo
