Andrew Pinski wrote:
We should also be very careful not to introduce differences between
native and cross compilers. So, we should have no run-time tests, no
tests that look at /proc, headers in /usr/include, etc.
Right--I was really only suggesting tests that can be done at
compile-time. Perh
>
> > We should also be very careful not to introduce differences between
> > native and cross compilers. So, we should have no run-time tests, no
> > tests that look at /proc, headers in /usr/include, etc.
>
> Right--I was really only suggesting tests that can be done at
> compile-time. Perhap
> We should also be very careful not to introduce differences between
> native and cross compilers. So, we should have no run-time tests, no
> tests that look at /proc, headers in /usr/include, etc.
Right--I was really only suggesting tests that can be done at
compile-time. Perhaps there isn't a
Ben Elliston wrote:
> So I take it that at this stage we've not commenced the process of
> having libgcc's configury run autoconf tests on the target compiler?
> (Rather than having to hardwire most target details into the t-* files?)
> Any objections to starting down this path?
We should also be
On Wed, 2007-01-03 at 23:28 -0500, Daniel Jacobowitz wrote:
> Right now the libgcc configuration is completely tied up with
> gcc/Makefile. As parts of the configuration process move from
> gcc/config/ to libgcc/config/ (or libgcc's configure.ac), we'll
> be untangling them. Eventually, it shoul
I've just committed the approved top level libgcc patches, which
create a top level "libgcc" directory.
Hopefully, this will not have any great impact on much of anyone.
The only change I know of is that if you run "make all-gcc", you will
no longer have enough to test C. You need at least "make
Not 4.3 but 3.4 yes the older version. And I built and installed mpfr
and gmp. gmp4.1 and mpfr 2.2. I dont have a /usr/local/lib64 on my
system. Did my mpfr/gmp install incorrecly ?
dz
On 1/3/07, Matt Fago <[EMAIL PROTECTED]> wrote:
You do mean gcc 4.3 right (either a snapshot, or from svn)?
You do mean gcc 4.3 right (either a snapshot, or from svn)?
Since you're running on x86_64, do you know that the libraries are
the correct bitness (running 'file' on the mpfr and gmp libraries
will tell). By default gcc on x86_64 will build 64-bit, but
libraries in /usr/local/lib should on
The only warning it reports is this immediately after detecting gmp and mpfr
*** This configuration is not supported in the following subdirectories:
target-libada gnattools target-libgfortran target-libffi
target-zlib target-libjava zlib target-libobjc target-boehm-gc
The other suggestions
On Wed, Jan 03, 2007 at 08:11:35PM -0500, drizzle drizzle wrote:
> Hi
> I have tried everything any page might say on this, still
> stuck. Any help would be great
> Hi all
>
> I am trying to install 3.4 on my AMD turion 64 machine with fedora
> core.
You mean 4.3 (or rather a snapshot or
Hi
I have tried everything any page might say on this, still
stuck. Any help would be great
Hi all
I am trying to install 3.4 on my AMD turion 64 machine with fedora
core. But run into messages like this on gmake. Configure is fine
libbackend.a(builtins.o): In function `fold_builtin_cbr
On Sun, 2006-12-24 at 09:08 +0100, Zdenek Dvorak wrote:
>
> As expected, more complications than I believed appeared. The changes
> to bsi_remove and release_defs would be basically sufficient for ssa
> names for real operands, however we are losing ssa names for virtual
> operands everywhere, a
On Tue, 2007-01-02 at 15:43 -0800, Adam Nemet wrote:
> If it is not too late I'd prefer the latter. If I understand the
> problem correctly the former would still fail if the test user is not
> privileged enough to recreate the directory structure under /.
Yes, that is correct. OK, having given
>
> We're planning to merge the 'gcj-eclipse' branch back to the trunk
> this week. This branch holds a major overhaul of gcj, and in
> particular changes gcj to use the Eclipse java compiler as a kind of
> preprocessor. This change was approved by the GCC Steering Committee.
Can you wait 24 ho
We're planning to merge the 'gcj-eclipse' branch back to the trunk
this week. This branch holds a major overhaul of gcj, and in
particular changes gcj to use the Eclipse java compiler as a kind of
preprocessor. This change was approved by the GCC Steering Committee.
Most of the changes on the br
On Wed, 3 Jan 2007, Dave Korn wrote:
Is that your idea of an apology? Regardless of topicality there's no
reasonable reading of Ian's words as a flame, they were entirely polite
and well-measured, and you should withdraw your baseless accusation and
say sorry rather than trying to rationalis
This is the beta release of binutils 2.17.50.0.9 for Linux, which is
based on binutils 2007 0103 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections f
On Wed, Jan 03, 2007 at 08:24:35PM -, Dave Korn wrote:
> On 03 January 2007 19:08, Adam Sulmicki wrote:
>
> > On Wed, 3 Jan 2007, Ian Lance Taylor wrote:
> >
> >> I told you was to use the gcc-help mailing list, which was correct.
> >
> >> So this seems to be a bug in gcc: it should be calli
On 03 January 2007 19:08, Adam Sulmicki wrote:
> On Wed, 3 Jan 2007, Ian Lance Taylor wrote:
>
>> I told you was to use the gcc-help mailing list, which was correct.
>
>> So this seems to be a bug in gcc: it should be calling _mcount.
>
> It just that it is my impression that gcc list is more
>
Laurent GUERBY wrote:
On Sun, 2006-12-31 at 12:04 -0500, Robert Dewar wrote:
Duncan Sands wrote:
The C front-end performs this transformation too. I'm not claiming that the
back-end optimizers would actually do something sensible if the front-end
didn't transform this code (in fact they don't
On Wed, 3 Jan 2007, Ian Lance Taylor wrote:
I told you was to use the gcc-help mailing list, which was correct.
So this seems to be a bug in gcc: it should be calling _mcount.
It just that it is my impression that gcc list is more
appropriate for gcc bugs than gcc-help.
I also did my bes
Andrew Haley <[EMAIL PROTECTED]> writes:
> Trivia time: what is the longest delay between a bug being committed
> to gcc before someone notices and a fix being committed? This one is
> eleven years and eight months. I wonder if we have a record.
As it happens, I can beat that. I've found a bug
H. J. Lu writes:
> On Wed, Jan 03, 2007 at 10:18:36AM -0800, Seongbae Park wrote:
> > >In fact, by default, gcc for the i386 targets will call _mcount. gcc
> > >for i386 GNU/Linux targets was changed to call mcount instead of
> > >_mcount with this patch:
> > >
> > >Thu Mar 30 06:20:36 1995
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> I remember someone wanting to provide his own mcount().
> Presumably, mcount() is weak in libc to cover such a use case ?
Yes, mcount() is weak in libc. But it seems to me that you can
provide your own mcount even if it has to be named _mcount, since
On Wed, Jan 03, 2007 at 10:18:36AM -0800, Seongbae Park wrote:
> >In fact, by default, gcc for the i386 targets will call _mcount. gcc
> >for i386 GNU/Linux targets was changed to call mcount instead of
> >_mcount with this patch:
> >
> >Thu Mar 30 06:20:36 1995 H.J. Lu ([EMAIL PROTECTED])
> >
On 03 Jan 2007 10:07:57 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Adam Sulmicki <[EMAIL PROTECTED]> writes:
> In spirit making OSS better, I took the extra effor to report
> findings back to both lists. In reward I got flamed on both list.
You got flamed on the gcc list? I
Adam Sulmicki <[EMAIL PROTECTED]> writes:
> In spirit making OSS better, I took the extra effor to report
> findings back to both lists. In reward I got flamed on both list.
You got flamed on the gcc list? I don't see any flames there. All I
told you was to use the gcc-help mailing
On Sun, 2006-12-31 at 12:04 -0500, Robert Dewar wrote:
> Duncan Sands wrote:
>
> > The C front-end performs this transformation too. I'm not claiming that the
> > back-end optimizers would actually do something sensible if the front-end
> > didn't transform this code (in fact they don't seem too)
i686-pc-linux-gnu
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /disk2/Downloads/gcc/gcc-4.1.1/configure
Thread model: posix
gcc version 4.1.1
Fedora Core release 5 (Bordeaux)
Kernel \r on an \m
Linux 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 i686 i686 i386
GNU/Linux
Hello folks,
This is my last post on the subject of mcount.
I have spent a quite bit of time on this to find out
that the results of myserious crashes is the mcount variable.
(with help from Ian Lance Taylor).
I have reported the issue to both gcc and mp
* Basile STARYNKEVITCH <[EMAIL PROTECTED]> [070102 22:49]:
> Maybe, instead of using built-ins, we could extend the __attribute__
> facility for functions (and expect the libc developers to progressively use
> them). Eg
>
>void free(void*) __attribute((pointer_invalid(1)));
>
> would mean tha
On Mon, 2007-01-01 at 22:27 -0500, Richard Kenner wrote:
> > I don't think -frisky is a good name for that option. A better name
> > would be -fstrict.
>
> Or -pedantic? ;-)
-pedantic-codegen
:)
Laurent
Andrew Pinski writes:
>
> This will always cause a trap on x86, even with -fwrapv so really
> -fwrapv has a bug on x86. I will file this bug sometime later
> tomorrow. Oh and fixing this bug will actually slow down users
> of -fwrapv even more than what it is currently does because
> you c
Paul Eggert <[EMAIL PROTECTED]> writes:
| Here are further patches I checked into the Autoconf documentation to
| reflect today's comments (some of which I received privately). Thanks
| to all of you. The trickiest bit was documenting one simple way to
| reliably detect overflow without converti
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > >> >> Many portable C programs assume that signed integer overflow wraps
around
| > >> >> reliably using two's complement arithmetic.
| > >> >
| > >>
| > >> I was looking for an adjective that m
Andrew Pinski <[EMAIL PROTECTED]> writes:
> the one thing I have not heard through this
> discussion is the real reason why the C standards comittee decided
> signed overflow as being undefined.
I wasn't there, but my impression is that many of the optimization
issues we've talked about in this t
36 matches
Mail list logo
