--- 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
--- 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 doe
--- 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.
--
http://gcc.gn
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 -c
--- 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=12534&action=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=gcc&view=rev&rev=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 i
--- 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 exposed/caused
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
reinitialize
--- 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 ch
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 us
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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
>
--- 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 t
--- 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=12535&action=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 t
--- 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=12536&action=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=gcc&view=rev&rev=118421
Log:
2006-10-13 David Edelsohn <[EMAIL PROTECTED]>
Ian Lanc
--- 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=gcc&view=rev&rev=118422
Log:
PR other/29639
* except.c (switch_to_ex
--- 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 the
--- 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=12537&action=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=gcc&view=rev&rev=118423
Log:
PR tree-optimization/27891
* tree-ssa-loop-iv
--- 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=gcc&view=rev&rev=118430
Log:
PR tree-optimization/27891
* tree-ssa-loop-iv
--- 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
--- 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=gcc&view=rev&rev=118435
Log:
PR target/27405
* config/sh/sh.md (cmp{eq,gt,
--- 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=rev&rev=110705
r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006)
--
http://gcc.gnu.or
--- 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 -DIN_LIBGCC2
--- 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=12539&action=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=12540&action=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=12541&action=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 11:44:36.0
--- 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
directo
--- 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 compil
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
47 matches
Mail list logo
