--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-19 06:02 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-19 05:59 ---
I can reproduce the ICE on i686-linux-gnu with a native compiler with the
preprocessed source.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-19 05:49 ---
> I know you're on vacation, Paul, but I think what looks troubling to us would
> look trivial to you, friendly as you are with the module code in gfortran!
>
I'll have a look today - I am in the midst of a triage of
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-08-19 03:29
---
Here is a comparison of no optimization and with -O1. Does this code look the
same on x86-64 that is not FreeBSD?
Code with no optimization: This does not work.
call_gfortran_st_write_done
m
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-19 03:03 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #39 from hubicka at ucw dot cz 2006-08-19 01:51 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
The -O1 time sinks:
life analysis : 25.44 (19%) usr 0.00 ( 0%) sys 25.49 (17%) wall
2565 kB ( 2%) ggc
inline heur
--- Comment #38 from hubicka at ucw dot cz 2006-08-19 00:19 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
At -O0 we get time sinks:
life analysis : 0.75 (10%) usr 0.01 ( 3%) sys 0.78 ( 9%) wall
2714 kB ( 4%) ggc
expand
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-18 23:31 ---
A regression hunt using "-O2 -w -fmove-loop-invariants" on powerpc-linux
identfied the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=99547
r99547 | rakdver | 2005-05-10 22:33:30 + (Tue, 10 May
--- Comment #37 from hubicka at ucw dot cz 2006-08-18 23:10 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
to summary current process, the memory consumption seems to be in
control now:
comparing PR rtl-optimization/28071 testcase co
--- Comment #8 from janis at gcc dot gnu dot org 2006-08-18 22:20 ---
A regression hunt on powerpc-linux using the testcase from comment #4
identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=110852
r110852 | rakdver | 2006-02-10 21:01:10 + (Fri, 10 Feb
--- Comment #3 from lucier at math dot purdue dot edu 2006-08-18 21:34
---
Created an attachment (id=12094)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12094&action=view)
preprocessed source for dwarf2out.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
--- Comment #10 from janis at gcc dot gnu dot org 2006-08-18 21:30 ---
A regression hunt on powerpc-linux using the submitter's testcase identified
the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=69921
r69921 | nathan | 2003-07-29 11:16:50 + (Tue, 29 Jul 2003)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 21:27 ---
http://gcc.gnu.org/ml/gcc-regression/2006-08/msg6.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 21:26 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-18 21:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 21:15 ---
Here is a full testcase:
typedef long GLint;
void aglChoosePixelFormat(const GLint *);
void find(const int *alistp) {
const int *blist;
int list[32];
if (alistp)
blist = alistp;
else {
list[3] = 42;
--- Comment #2 from mrs at apple dot com 2006-08-18 21:12 ---
radr://4658741
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 21:11 ---
As long as aglChoosePixelFormat only access the argument as int and not long,
this should be ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 21:08 ---
This is most likely a dup of another bug which was fixed in 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
mrs $ cat /tmp/t2.cc
typedef long GLint;
void aglChoosePixelFormat(const GLint *);
void find(const int *alistp) {
const int *blist;
int list[32];
if (alistp)
blist = alistp;
else {
list[3] = 42; /* this store disappears with -fstrict-aliasing */
blist = list;
}
aglCho
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-08-18 20:54
---
Here is a debug trace showing the steps leading up to the mutation of the dtp
pointer. StevebB on IRC indicated that the assembly output on linux x86-64
natch the freebsd version I posted here and the problem doe
Compiling the following code with -O2 produces an buggy excecutable:
(Using no optimization or -O1 produces an valid excecutable)
~~~ snip ~~
#include
int main( void )
{
for ( int i = 1; i != 0; i = i + 1 )
{
if ( ! (i %
configure and build:
/bin/rm -rf *; ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/
--with-mpfr=/opt/local/ ; make -j 4 bootstrap >& build.log && (make -k -j 8
check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'" >& check.log ; make
mail-report-with-warnings.log)
with updat
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-08-18 19:16 ---
Subject: Bug 27565
Author: jsm28
Date: Fri Aug 18 19:16:19 2006
New Revision: 116250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116250
Log:
PR target/27565
* config/rs6000/rs6000.h (LOCAL_A
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-18 19:16 ---
(In reply to comment #6)
> The testcase in comment #4 is incomplete; I get all of these errors even with
> the current 4.1-branch on powerpc-linux:
Janis, this is C code and not C++ code :).
--
http://gcc.gnu.o
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-08-18 19:15 ---
Subject: Bug 27565
Author: jsm28
Date: Fri Aug 18 19:15:31 2006
New Revision: 116249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116249
Log:
PR target/27565
* config/rs6000/rs6000.h (LOCAL_A
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-18 19:13 ---
This happens when the first patch in PR 22368 is added.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from bero at arklinux dot org 2006-08-18 19:10 ---
The problem is that classpath.security gets installed to /usr/lib/security
only, but not /usr/lib64/security.
Running
cp /usr/lib/security/classpath.secruity /usr/lib64/security
after installing gcc fixes it.
--
htt
When trying to use gcj-dbtool (SVN rev. 116230) on x86_64, this happens:
gcj-dbtool -f ecj.db ecj.jar /usr/lib64/libecj.so.3
error: could not update ecj.db: java.security.NoSuchAlgorithmException: MD5
Works as expected with the same gcc/gcj on normal x86.
--
Summary: gcj-dbtool fail
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-18 18:29 ---
As the submitter of the patch, I suppose that I had better take on the PR!
Thanks for the report, Martin
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-18 18:28 ---
Andrew,
How, when and where does this happen, please?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28722
--- Comment #1 from patchapp at dberlin dot org 2006-08-18 18:20 ---
Subject: Bug number PR28771
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00668.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-18 18:04 ---
The testcase in comment #4 is incomplete; I get all of these errors even with
the current 4.1-branch on powerpc-linux:
elm3b11% /opt/gcc-nightly/4.1/bin/g++ -c 28753.cc
28753.cc:21: error: ISO C++ forbids declaration
In the code fragment
int i = static_cast(1.234);
int j = static_cast(1.234);
the const and volatile qualifiers in the cast are silently ignored, even with
-Wall -W -pedantic. A warning from g++ for this mild infraction would be
useful.
--
Summary: Request for warning where cons
--- Comment #7 from mueller at gcc dot gnu dot org 2006-08-18 17:55 ---
struct oD.1993:
type_0 type_5 type_6 BLK
size
constant invariant 0>
unit size constant invariant 0>
align 8 symtab 0 alias set -1
attributes
local bindings <(nil)>>
value
--- Comment #3 from simon_baldwin at yahoo dot com 2006-08-18 17:51 ---
Unfortunately, adding -pedantic brings in a grab-bag of other warnings that
aren't currently separable.
What would be useful, I think, is to have unknown escape sequences as its own
-Wmumble option. That way, it's
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-08-18 16:29
---
Using -fdump-tree-final_cleanup all looks OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
--- Comment #8 from jason at gcc dot gnu dot org 2006-08-18 16:28 ---
Subject: Bug 28385
Author: jason
Date: Fri Aug 18 16:28:15 2006
New Revision: 116244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116244
Log:
PR c++/28385
* pt.c (tsubst) [TEMPLATE_TYPE_PARM]
--- Comment #7 from jason at gcc dot gnu dot org 2006-08-18 16:27 ---
Subject: Bug 28385
Author: jason
Date: Fri Aug 18 16:27:03 2006
New Revision: 116243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116243
Log:
PR c++/28385
* pt.c (tsubst) [TEMPLATE_TYPE_PARM]
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
--- Comment #22 from bonzini at gnu dot org 2006-08-18 16:16 ---
patch withdrawn, I'll wait for pinskia's
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-18 16:15 ---
(In reply to comment #1)
> Middle-end or backend problem?
Can you look at the dump that is produced by -fdump-tree-final_cleanup
and see if it is correct?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28747
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-08-18 16:12
---
Simplified test case used in discussion above.
program streamtest
implicit none
real, dimension(2,3) :: anarray
open(10, file="teststream", access="stream", form="unformatted")
anarray = 3.14159
write(1
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-08-18 16:08
---
Created an attachment (id=12093)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12093&action=view)
assembly output for reduced case
There is wrong code generated setting up the parameters for the second call
--- Comment #7 from ian at airs dot com 2006-08-18 15:58 ---
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28765
--- Comment #6 from pcarlini at suse dot de 2006-08-18 15:44 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from paolo at gcc dot gnu dot org 2006-08-18 15:42 ---
Subject: Bug 28765
Author: paolo
Date: Fri Aug 18 15:42:27 2006
New Revision: 116241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116241
Log:
2006-08-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from paolo at gcc dot gnu dot org 2006-08-18 15:42 ---
Subject: Bug 28765
Author: paolo
Date: Fri Aug 18 15:42:05 2006
New Revision: 116240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116240
Log:
2006-08-18 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #9 from bonzini at gnu dot org 2006-08-18 15:36 ---
> Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?
No. :-(
> The problem I have is that I am nearly always using the latest binutils
> because I did not get many regressions, but I sometimes rege
--- Comment #5 from sgilbertson at gcc dot gnu dot org 2006-08-18 15:33
---
The "ugly workaround" (which works great for my static builds!) patches a
previous workaround:
http://gcc.gnu.org/ml/java-patches/2006-q1/msg00181.html
So this issue is related to #13212,which is assigned to Bry
--- Comment #8 from etienne_lorrain at yahoo dot fr 2006-08-18 15:04
---
> For 4.2.0, it will find it and use it:
Will that be in 4.1.2 (or is it in 4.1 prereleases) or only appear in 4.2 ?
> > I was thinking "combined tree" was not as good, mostly because I had to
> > select whic
--- Comment #3 from schwab at suse dot de 2006-08-18 14:50 ---
scheduling:6473.35 (100%) usr 0.60 (88%) sys6473.98 (100%) wall
499608 kB (90%) ggc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28772
--- Comment #7 from paolo dot bonzini at lu dot unisi dot ch 2006-08-18
14:08 ---
Subject: Re: one reference to powerpc-ibm-eabi-ar.exe
when only xar.exe installed
etienne_lorrain at yahoo dot fr wrote:
> --- Comment #6 from etienne_lorrain at yahoo dot fr 2006-08-18 13:55
> --
--- Comment #6 from etienne_lorrain at yahoo dot fr 2006-08-18 13:55
---
I do have $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
and I am using $(HOME)/local/bin/xar.exe for my stuff here, after install.
To bootstrap, GCC may better use $(HOME)/local/powerpc-ibm-eabi/bin/ar.exe
but that
--- Comment #5 from bonzini at gnu dot org 2006-08-18 13:34 ---
Anyway, the simplest solution for you is to build in a combined tree:
cd build && rm -rf ppc_combined_src ppc_combined && \
mkdir ppc_combined_src ppc_combined
cd build/binutils-$(BINUTILS_VERSION)
--- Comment #4 from bonzini at gnu dot org 2006-08-18 13:28 ---
No, I was misreading the binutils Makefile.
Etienne, can you confirm that you have $(HOME)/local/powerpc-ibm-eabi/bin/ar ?
It is fixed in 4.2.0 if this is the case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28770
--- Comment #3 from bonzini at gnu dot org 2006-08-18 13:18 ---
If I remember/understand correctly, this "happened to work" in older GCC
releases (that is, the program prefix was added automatically if no other
target tool was found), except that after the installation GCC would forget
t
--- Comment #1 from berndtrog at yahoo dot com 2006-08-18 12:59 ---
Fixed in r114758. Thanks!
--
berndtrog at yahoo dot com changed:
What|Removed |Added
Statu
--- Comment #2 from bonzini at gnu dot org 2006-08-18 12:47 ---
Not an infinite loop.
100 lines => 0.47 sec
200 lines => 0.95 sec
1000 lines => 6.16 sec
1500 lines => 11.19 sec
2000 lines => 18.11 sec
2500 lines => 27.26 sec
3000 lines => 37.83 sec
3200 lines => 42.72 sec
3340 lines =>
--- Comment #2 from berndtrog at yahoo dot com 2006-08-18 12:47 ---
Atmel's new devices where added in r113982. Thanks!
--
berndtrog at yahoo dot com changed:
What|Removed |Added
-
--- Comment #2 from etienne_lorrain at yahoo dot fr 2006-08-18 12:25
---
I change --target=powerpc-ibm-eabi to --target=powerpc-eabi and
--enable-languages=c to --enable-languages=c,c++ but the configure
should be the same, I do not know what means "pre-installed"...
# rm -rf build
--- Comment #2 from patchapp at dberlin dot org 2006-08-18 12:20 ---
Subject: Bug number PR28762
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00641.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #9 from bonzini at gnu dot org 2006-08-18 12:07 ---
patch bootstrapped & tested on ia64, ppc, x86_64, s390, everywhere including
ada but not java, w/ no regressions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
--- Comment #1 from schwab at suse dot de 2006-08-18 11:49 ---
Created an attachment (id=12092)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12092&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28772
The scheduler apparently infloops on the attached test case when compiling with
-O2.
#0 internal_state_transition (insn_code=114, chip=0x6019ed70)
at ../../gcc/config/ia64/itanium2.md:125927
#1 0x406e81d0 in schedule_block (b=,
rgn_n_insns=20657) at ../../gcc/haifa-sched
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-18 11:47 ---
powerpc-ibm-eabi-ar.exe should have been installed by binutils unless you are
doing a combined tree but since you are using a program prefix the problem is
that GCC does not take that into account for the ar, I think
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-18 11:42 ---
(In reply to comment #6)
> Sorry, but I didn't know that. I reported the bug against GCC 4.1.1 and the
> target milestone set for it is GCC 4.1.2. So, I expected that patch to work
> with gcc 4.1.x. The 'force_align_
As far as I know, the following code snippet is not valid Fortran:
program test
character(len=*) :: foo = 'test'
end
To make the code correct, the variable definition either needs the "parameter"
attribute or an explicit length.
Other compilers (Intel, Fujitsu and NAG) reject this code, but all
--- Comment #3 from doko at ubuntu dot com 2006-08-18 11:38 ---
Created an attachment (id=12091)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12091&action=view)
example
more simple example from the gettext source, compiled with
gcj -C gnu/gettext/GetURL.java
gcj -v -fjni -findir
--- Comment #8 from zak at transversal dot com 2006-08-18 11:21 ---
However, that patch breaks the following code, which requires *implicit*
derived-to-base conversion:
struct Z {};
struct A : Z {};
Z* implicitToZ (Z*);
struct B : A
{
static
--- Comment #10 from dwmw2 at infradead dot org 2006-08-18 11:11 ---
I've hacked around this for now by reverting the patch for PR25795 and doing
this instead:
--- gcc/c-decl.c~ 2006-01-19 23:48:07.0 +
+++ gcc/c-decl.c2006-08-15 21:43:43.0 +0100
@@ -166
Unlike with GCC-3.*, building GCC-4.1.1 PPC crosscompiler from a bootstrapped
native GCC-4.1.1 and binutils-2.17 on cygwin fails because of a small error.
Using a new and up to date Cygwin install.
xgcc -v (after fix) gives:
Using built-in specs.
Target: powerpc-ibm-eabi
Configured with: ../gcc-4.
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-18 10:01 ---
Created an attachment (id=12090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12090&action=view)
Fix for the problem
This is regtesting right now - I have to go and cut a hedge... a huge hedge
(*sigh*)... but I
--- Comment #3 from pcarlini at suse dot de 2006-08-18 08:31 ---
Ok, I see... Then I will do the change, a little embarassing ;) By the way, if
it's not obvious, the reason we don't simply call _M_set_length is the other
base class, where clear cannot be trivial (due to refcounting) and
--- Comment #5 from dwmw2 at infradead dot org 2006-08-18 08:10 ---
Yep, I got the mail. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28714
--- Comment #6 from magsilva at gmail dot com 2006-08-18 07:16 ---
Sorry, but I didn't know that. I reported the bug against GCC 4.1.1 and the
target milestone set for it is GCC 4.1.2. So, I expected that patch to work
with gcc 4.1.x. The 'force_align_arg_pointer' attribute is available
76 matches
Mail list logo
