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
* 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 <[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
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 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
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
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
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 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
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])
> >
"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
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
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
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
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)
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 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
>
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
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, 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
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
>
> 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
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
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
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 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
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
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
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)?
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
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
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
> 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
>
> > 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
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
36 matches
Mail list logo
