On 02 November 2006 06:10, Steven Bosscher wrote:
On 11/2/06, Roger Sayle [EMAIL PROTECTED] wrote:
Steven Bosscher might even have plans for reorganizing jump bypassing
already as part of his CSE/GCSE overhaul?
Yes, and one part of that plan is to pre-split all critical edges so
that you
On Wed, Nov 01, 2006 at 03:05:33PM -0800, Mark Mitchell wrote:
I think it would be better to have GLIBC changed before changing the
behavior of the compiler. It might even be better to have a released
version of GLIBC with the changes. fixincludes causes sufficient
problems for people
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that no-one has really objected to stronger type-checking
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC
from 3.3 - 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the
fix has been
On 02 November 2006 13:12, Gerald Pfeifer wrote:
On Thu, 26 Oct 2006, Brooks Moses wrote:
I would say, on looking at it, that the order of items under Status is
slightly confusing; it seems to me that Active Development ought go
next to Next Release Series.
That's a good point.
From a
Mark Shinwell [EMAIL PROTECTED] writes:
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that
PR 29145 is about an over-aggressive use of restrict. So far it's had
only one response, and it was left in the UNCONFIRMED state.
tree-data-ref.c says this:
/* An instruction writing through a restricted pointer is independent of
any
instruction reading or writing through a different
On Nov 2, 2006, at 5:33 AM, Mark Shinwell wrote:
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that
Hello!
Does anybody else get these errors in libgfortran during clean bootstrap:
...
lots of similar errors involving lots of functions
...
.libs/environ.o(.text+0x10d0):/usr/include/stdlib.h:401: first defined here
.libs/in_unpack_generic.o(.text+0x730): In function `atol':
Hello!
Does anybody else get these errors in libgfortran during clean bootstrap:
...
lots of similar errors involving lots of functions
This happens on x86_64-pc-linux-gnu and i686-pc-linux-gnu, FC4.
Yes and it was already discussed in
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
Ian Lance Taylor wrote:
I would vote for: break the code, but provide an option to restore the
old behaviour, and mention the option in the error message.
I like this -- I shall prepare a patch and circulate it for review.
Mark
On Nov 1, 2006, at 8:10 PM, Andrew Pinski wrote:
We don't reject this TU during compiling but the assembler does. Is
this correct or should we actually reject this during compiling?
If you add any checking code, also consider:
int i asm(r1);
int j asm(r1);
Snapshot gcc-4.0-20061102 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello,
I am trying to get gcc to optimize an inner math loop. The first part
of the loop computes a single precision float expression (which may or
may not be NAN), and the second part sums all of these results into a
double precision total:
Conceptually, the code is:
double sum = 0;
for(i=0;
I am having difficulty getting configure properly regenerated in
libjava so that Geoff's multilib changes will take effect. What
versions of automake and libtool is required by the current gcc 4.2
branch?
The safest thing to do is to always look at the top of the file you're
trying to
What might be functional specifications for a GCC porting
project.Output format and ABI might be included in functional
specification.
Yes--output format would include the object file format and debugging
format. Something else that might wish to be thought about upfront is
Ben,
I believe I have puzzled out my problem. Geoff's multilib
changes needs a patch for the zlib and libjava configure.ac
(matching what he did for that file in libobjc). I have been
able to obtain a complete build for c, c++, objc and fortran
now on a G4 under Darwin8 after patching the
I keeping getting this error, though it gets less and less each day.
platform it i686-pc-cygwin.
I am not sure if this has been discussed before or similar discussions.
gmp 4.2.1 and mpfr 2.2, up to date as of today.
main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
Michael James wrote:
Conceptually, the code is:
double sum = 0;
for(i=0; in; ++i) {
float x = ..computed..;
sum += isnan(x)? 0: x;
}
I have tried a half dozen variants at the source level in attempt to
get gcc to do this without branching (and without calling a helper
function
Hi All,
GCC 4.1.1
This small bit of code from one of the test suites (
gcc.c-torture/execute/20020611-1.c)worked fine with all optimization
except size optimization -Os.
unsigned int p;
unsigned int n = 30;
void x ()
{
unsigned int h;
h = n = 30; // Line 1
if (h)
p = 1;
else
p = 0;
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2006-11-02 08:03
---
I think Roger is OK in principle with a backport, but the
questions are (a) whether we should keep your patch on
mainline too and, if not, (b) whether we should revert
it on the branches too. Roger, let me
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-02 09:47
---
(In reply to comment #1)
I presented a patch for this problem and for detected unassigned r-values that
was rejected. I don't know what to say; I think that it's a bug, in
principle,
but the standard does
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-11-02 10:25
---
Yes since it just went in during the time frame you mentioned:
2006-10-28 Eric Botcazou [EMAIL PROTECTED]
My bad. Patch crossing with Richard S. section anchor stuff. Testing fix.
--
While building liboil-0.3.9 on GNU/Linux:
http://liboil.freedesktop.org/download/liboil-0.3.9.tar.gz
I got:
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -msse -msse2 -Wall -D_BSD_SOURCE
-D_GNU_SOURCE -I../.. -g -O2 -MT libsse_la-composite_sse_2pix.lo -MD -MP -MF
.deps/libsse_la-composite_sse_2pix.Tpo
--- Comment #1 from sick_soul at yahoo dot it 2006-11-02 10:31 ---
Created an attachment (id=12534)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12534action=view)
console build log
added console log (text/plain)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29687
--- Comment #10 from vprus at gcc dot gnu dot org 2006-11-02 10:39 ---
Subject: Bug 28400
Author: vprus
Date: Thu Nov 2 10:39:33 2006
New Revision: 118414
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118414
Log:
2006-11-02 Vladimir Prus [EMAIL PROTECTED]
Backport
--- Comment #4 from irar at il dot ibm dot com 2006-11-02 11:18 ---
The loop at config/rs6000/rs6000.c:3674 requires versioning for alignment, so
when bootstrapping with
-ftree-vectorize -fno-tree-vect-loop-version it does not get vectorized.
However, we still fail bootstrap... This is
--- Comment #5 from irar at il dot ibm dot com 2006-11-02 11:44 ---
I found that revision 110671 passed bootstrap with vectorization enabled, and
revision 110846 failed bootstrap with vectorization enabled (but passed w/o).
Janis - could you help track down the patch that
in valarray.h I found that resize is always deleting the old array,
reallocating a new array and initialize to the value specified. The text book
(Stroustrup) indicates that only the newly allocated elements should be
initialized. In my case the array size was not changed but the array
--- Comment #1 from pcarlini at suse dot de 2006-11-02 13:34 ---
I do not have Stroustrup at hand, but certainly the ISO C++ Standard 2003, the
real reference for our work (we are implementing it), says, in 26.3.2.7/9, that
resize first changes the length of *this to sz and then assigns
--- Comment #2 from falk at debian dot org 2006-11-02 13:36 ---
Please attach the .i file as obtained by adding -save-temps. Also, please try a
newer gcc version, the 3.3 branch is dead.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2006-11-02 13:40 ---
Confirmed with a native 4.1.2 20061020.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2006-11-02 13:51 ---
The only possible change I can see, as an optimization, is using
__valarray_fill instead of __valarray_destroy_elements and
__valarray_fill_construct, when _M_size == __n. Let's ask Gaby...
--
pcarlini at suse dot de
There's a thread [EMAIL PROTECTED] started from emacs developers wishing that
gfortran used a g77-compatible error message format, starting here:
http://gcc.gnu.org/ml/fortran/2006-10/msg00751.html The friendly discussion has
been a bit heated.
I don't think anybody disagrees with the fact that
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-02 14:34
---
Some incomplete patch proposals here:
http://gcc.gnu.org/ml/fortran/2006-10/msg00825.html and there:
http://gcc.gnu.org/ml/fortran/2006-11/msg00017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
--- Comment #30 from ghazi at gcc dot gnu dot org 2006-11-02 14:41 ---
(In reply to comment #28)
(In reply to comment #27)
It's likely that I'll end up doing it, so would you please tell me how?
According to the C rationale (I haven't checked), the sign of gamma(x) is -1
if
[iff]
--- Comment #3 from theo dot bosman at net dot HCC dot nl 2006-11-02 15:56
---
Subject: Re: resize initializes whole array
There is no argument against the ISO standard, but to a non C/C++ programmer
it seems a waist of time to reallocate the array and initialize it when one
wants
--- Comment #31 from vincent at vinc17 dot org 2006-11-02 15:57 ---
(In reply to comment #30)
So, I don't think a mpfr_signgam alone would really be useful. So, I think that
choice 2 would be better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-02 16:02 ---
Created an attachment (id=12535)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12535action=view)
Idea how libgfortran/intrinsic/system_clock.c could look like
Some bits of thought.
Methods obtaining the time:
--- Comment #3 from ian at airs dot com 2006-11-02 16:07 ---
This looks like a compiler bug to me. The code in base_addr_differ_p seems
dubious anyhow: in principle,may_alias_p should handle restrict, it shouldn't
be handled by the caller.
It looks like this code has been there since
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-02 16:10 ---
Confirmed. (this is also why effective restrict is hard to do without better
PTA)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-02 16:32 ---
Created an attachment (id=12536)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12536action=view)
Revised idea how libgfortran/intrinsic/system_clock.c could look like
The latter part is of cause not completely
--- Comment #7 from peter at chocky dot org 2006-11-02 16:34 ---
I can confirm that this is fixed with the GCC 4.1 now in Debian unstable.
--
peter at chocky dot org changed:
What|Removed |Added
--- Comment #12 from dje at gcc dot gnu dot org 2006-11-02 17:19 ---
Subject: Bug 29250
Author: dje
Date: Thu Nov 2 17:18:52 2006
New Revision: 118421
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118421
Log:
2006-10-13 David Edelsohn [EMAIL PROTECTED]
Ian Lance
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-11-02 18:41
---
Subject: Bug 29639
Author: ebotcazou
Date: Thu Nov 2 18:40:54 2006
New Revision: 118422
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118422
Log:
PR other/29639
* except.c
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-11-02 18:44
---
Should work now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
The attached program writes to buf[16] using sprintf. The format writes 15
characters and then explicitly appends a \0 byte using %c. Subsequently sprintf
will implicitly append another \0 byte itself so that in total 17 bytes are
written to buf, i.e. 1 byte too many. One can readily check that
--- Comment #1 from p dot vanhoof at oma dot be 2006-11-02 18:47 ---
Created an attachment (id=12537)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12537action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29691
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-11-02 19:18 ---
Subject: Bug 27891
Author: rakdver
Date: Thu Nov 2 19:18:25 2006
New Revision: 118423
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118423
Log:
PR tree-optimization/27891
*
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-11-02 20:57 ---
Subject: Bug 27891
Author: rakdver
Date: Thu Nov 2 20:57:35 2006
New Revision: 118430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118430
Log:
PR tree-optimization/27891
*
--- Comment #32 from ghazi at gcc dot gnu dot org 2006-11-02 22:44 ---
(In reply to comment #31)
(In reply to comment #30)
So, I don't think a mpfr_signgam alone would really be useful. So, I think
that
choice 2 would be better.
Okay, sounds fine. Would this make it into 2.2.1 or
--- Comment #3 from kkojima at gcc dot gnu dot org 2006-11-02 22:57 ---
Subject: Bug 27405
Author: kkojima
Date: Thu Nov 2 22:57:13 2006
New Revision: 118435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118435
Log:
PR target/27405
* config/sh/sh.md
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-02 23:42 ---
PR 5773 is about addr2line in gcj.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-11-02 23:52
---
We can fork+exec addr2line, but we can't link libbfd because it's GPL.
It was mentionned on IRC tonight that Daniel Berlin has a library that extracts
line and file information from DWARF2 info. It's internal to
--- Comment #4 from pcarlini at suse dot de 2006-11-03 00:08 ---
(In reply to comment #3)
Subject: Re: resize initializes whole array
There is no argument against the ISO standard, but to a non C/C++ programmer
it seems a waist of time to reallocate the array and initialize it
--- Comment #6 from janis at gcc dot gnu dot org 2006-11-03 00:08 ---
A regression hunt on powerpc64-linux identified the following large patch:
http://gcc.gnu.org/viewcvs?view=revrev=110705
r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006)
--
--- Comment #18 from pcarlini at suse dot de 2006-11-03 00:29 ---
Thanks again for the quick fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29639
This was the error I got from gcc-4.1.1 while attempting to compile gcc-3.4.3.
$ arm-none-linux-gnueabi-gcc -O2 -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT
--- Comment #1 from mriben at globallocate dot com 2006-11-03 02:08 ---
Created an attachment (id=12539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12539action=view)
unwind-dw2.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
--- Comment #2 from mriben at globallocate dot com 2006-11-03 02:09 ---
Created an attachment (id=12540)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12540action=view)
unwind-dw2.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
--- Comment #2 from brooks dot moses at codesourcery dot com 2006-11-03
02:52 ---
Created an attachment (id=12541)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12541action=view)
Proposed patch including testsuite changes
I attempted to send this to the list, but I'm not sure if
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2006-11-03
03:14 ---
I can now complete a multilib build of the languages c, c++, objc and fortran
on a G4 under Darwin8 if I apply the following patch...
--- gcc-4.2-20061031/zlib/configure.ac.org 2006-11-02
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2006-11-03
03:36 ---
After patching configure.ac and regenerating configure in zlib with...
aclocal -I ../config
autoreconf -I ../config
I find that I don't get a zlib subdirectory in the powerpc-apple-darwin8 build
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-11-03 04:07
---
I will give it a spin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29689
--- Comment #5 from fang at csl dot cornell dot edu 2006-11-03 07:28
---
There is no argument against the ISO standard, but to a non C/C++ programmer
it seems a waist of time to reallocate the array and initialize it when one
wants to add something to an array. Some other
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
67 matches
Mail list logo
