This is now in bugzilla as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
-benjamin
When I run bootstrap and make check, I check the -m64 option
(only). Check gcc-testresults.
Currently, the results don't look very good. Maybe I'm doing
something wrong.
Brad
Brad,
Why don't you try a normal multi-lib build without any
extra flags. At the moment, considering how much noise is on
the testsuite results on Darwin due to this linker warnings, I
don't think its really helpful to bother exploring corner cases
of building gcc trunk with unique flags. Make
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
Interesting email. One question: how big are the
On Aug 28, 2006, at 12:10 PM, Jack Howarth wrote:
Why don't you try a normal multi-lib build without any
extra flags.
What extra flags? The configure command is
../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --
with-mpfr=/opt/local/
which is totally generic (one
Chris Lattner wrote:
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
Interesting email. One
Richard Kenner wrote:
I disagree. Testing is not, and should never be, a substitute for analysis.
A patch is proposed because we have a reason to believe it's correct. Then
we test to increase our confidence that it is, indeed, correct. But both
parts are essential for any patch.
Here
Brad,
I was confusing your use of -mcpu=970 in the make check with the
build flags...sorry. You might stop using that flag for now until
you get a baseline of how many additional failures seen in -m64
compared to -m32 are not due to the linker warnings (after you
apply the TImode patch). I'll
On Aug 27, 2006, at 7:24 AM, Jack Howarth wrote:
Can one of you remind me who we need to lobby at Apple
In the gcc project, contributions are generally speaking, made by an
individual. Geoff operates a regression tester, probably the one
you're thinking of. In the past, he has considered
Mike,
Do you know if regress is used for anything other than building
and checking gcc? Also is it a dual G5 by any chance? I ask because
it is unclear if regress is doing a 'make -k -j 2 check' or not?
Might that not increase the rate of testing on regress? I haven't
tried that myself because
On Aug 28, 2006, at 10:36 AM, Kenneth Zadeck wrote:
I actually do not think that it is productive to spend that much time
measuring this until we first assure ourselves that we are getting all
of the information output correctly. That 60mb number will change
a lot
(both up and down) as we
On Aug 28, 2006, at 1:20 PM, Jack Howarth wrote:
Might that not increase the rate of testing on regress?
Sorry, nope.
On 8/27/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
I have not received reports about bugs in the offending code when
compiled with other compilers.
I do know at least one another compiler that does this,
and at least one significant project (which is actually quite a bit
larger than
Mike,
Well then alternatively, might not 'make -j 2' increase
the rate at which gcc is built on regress? Or doesn't Darwin
support parallel builds? If we can't speed up the testing
then we could at least speed up the build process to free
up time for -m64. After all, we are already building
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote:
Well then alternatively, might not 'make -j 2' increase the rate at
which gcc is built on regress?
Yes, we know about -j2. When I said, sorry, nope, I meant to convey
the idea that in fact that adding a -j2 won't speed it up.
Or doesn't
Mike,
Now I totally confused. Are you saying that '-j 2' only speeds up
testing but not builds? In one sentence you say it won't speed things up
and in the next you say of course it speeds things up. Which is it?
Jack
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote:
On Aug 28, 2006, at 3:57 PM, Jack Howarth wrote:
If we can't speed up the testing
? -j2 makes testing go faster as well.
Sigh, I misstated that one. My comment in that case was about the
general case. I meant to say that -j2 is as applicable to testing as
it is to
Mike,
Okay. How about this. Have regress set to at least do
a -m64 make check once a week. At least that would show
some interest in the status of gcc at 64-bit. It is baffling
to most people how we can make any progress on such issues
if the status isn't sampled at least once every blue moon.
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
I have only a limited understanding of GIMPLE and LTO, but here are my
comments
Mike,
Sure. I am actually doing a build right now to demonstrate the
baseline we have for c, c++, and fortran with just the TImode patch
and the prune.exp patches I use. Hmm, regress is a G4...surely you
can find a G5 laying around Apple to replace it with since PowerPC
is so passe there
Michael Eager wrote:
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
I have only a limited understanding of GIMPLE and LTO,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 06:01 ---
This is weird, this code is a regression also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-28 06:06 ---
Evening adding one more variable causes 3.2.3 to optimize this. I don't know
what does the optimization on the rtl level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
--- Comment #18 from bernie at develer dot com 2006-08-28 06:18 ---
(In reply to comment #17)
And that is Redhat's branch which has the patch which caused this in the first
place on it.
Thus, I've filed a bug report in RedHat's bugzilla:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-28 06:43 ---
If I do this:
int f(int t, int a, int b)
{
int c, d, e;
if (t)
{
c = a+1;
d = a+1;
e = a+1;
}
else
{
c = b+1;
d = b+1;
e = b+1;
}
return c+d+e;
}
We get the extra moves
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org
|dot org
--- Comment #17 from laurent dot deniau at cern dot ch 2006-08-28 07:42
---
Subject: Re: [4.0 Regression] Very high compile time
echristo at apple dot com wrote:
--- Comment #16 from echristo at apple dot com 2006-08-26 00:10 ---
Should this be closed as unlikely to fix in
--- Comment #12 from christian dot joensson at gmail dot com 2006-08-28
08:12 ---
(In reply to comment #11)
Fixed on the mainline, will apply to the branches after a week or so.
So, how's this going for 4.1?
--
christian dot joensson at gmail dot com changed:
What
--- Comment #7 from jason at gcc dot gnu dot org 2006-08-28 08:31 ---
Or perhaps we should ignore the __attribute__ ((packed)) on nonpod_pack, since
one of its fields isn't safe to pack. Yes, that seems like the right way to
handle this testcase.
--
--- Comment #29 from rguenth at gcc dot gnu dot org 2006-08-28 08:42
---
I completely agree with Dan's analysis. Note that for the patch in comment #20
we can hoist the loop adding all addressable vars to the call clobbering list
out of the loop iterating over all analyzed pointers by
When building gcc-4.1.1 with the following configuration:
../gcc-4.1.1/configure --prefix=/opt --with-local-prefix=/opt/include
--with-cpu=ultrasparc --enable-languages=c,c++,java
The build fails to build libjava with the following error:
Adding multilib support to Makefile in
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-08-28 09:49 ---
Just a note.
The current behavior is as intended, although perhaps not documented. I'll be
fixing that later today.
Here's a message from last month detailing in advance this exact bug report:
--- Comment #14 from pcarlini at suse dot de 2006-08-28 09:58 ---
(In reply to comment #13)
The real issue is: code independent from the atomicity model. The only way
to have this is to not inline the atomic helper functions in atomicity.h. I am
willing to revert that part of my
--- Comment #15 from pcarlini at suse dot de 2006-08-28 10:02 ---
(In reply to comment #14)
Sorry about my crazy english today, I'm concentrated on something else...
Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only
option, at the moment. For ia64, powerpc,
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-08-28
11:56 ---
Created an attachment (id=12146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12146action=view)
Fix and two test cases for the latest regressions
I post this now, as a prelude to submitting the
--- Comment #13 from jakub at gcc dot gnu dot org 2006-08-28 12:22 ---
Subject: Bug 21764
Author: jakub
Date: Mon Aug 28 12:22:14 2006
New Revision: 116504
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116504
Log:
2006-03-20 Jason Merrill [EMAIL PROTECTED]
PR
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 28279
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #6 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 26612
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 28215
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 19134
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 26905
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 26984
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #11 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 27000
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #11 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 17470
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 21675
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #19 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 21581
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
--- Comment #13 from jakub at gcc dot gnu dot org 2006-08-28 12:27 ---
Subject: Bug 25915
Author: jakub
Date: Mon Aug 28 12:26:41 2006
New Revision: 116505
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505
Log:
2006-07-06 Jason Merrill [EMAIL PROTECTED]
cp/
PR
This change:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01487.html
Has caused problems with people who set a custom timeout value in .exp files.
Examples include:
http://gcc.gnu.org/ml/gcc/2006-08/msg00371.html
and
http://gcc.gnu.org/ml/libstdc++/2006-08/msg00027.html
Mike's suggestion to do
--- Comment #13 from jakub at gcc dot gnu dot org 2006-08-28 12:29 ---
Subject: Bug 28370
Author: jakub
Date: Mon Aug 28 12:28:55 2006
New Revision: 116506
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116506
Log:
PR c++/28370
* decl2.c (note_vague_linkage_var):
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-28 12:31 ---
Subject: Bug 28409
Author: jakub
Date: Mon Aug 28 12:31:26 2006
New Revision: 116507
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116507
Log:
2006-07-20 Jason Merrill [EMAIL PROTECTED]
* tree.c
--- Comment #12 from jakub at gcc dot gnu dot org 2006-08-28 12:31 ---
Subject: Bug 28407
Author: jakub
Date: Mon Aug 28 12:31:26 2006
New Revision: 116507
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116507
Log:
2006-07-20 Jason Merrill [EMAIL PROTECTED]
* tree.c
Sometime between Aug 1, 2006 and Aug 22, 2006 the time needed to run the g++
and libstdc++ testsuite ballooned.
See this message and followups:
http://gcc.gnu.org/ml/gcc/2006-08/msg00398.html
Here are the specifics that I have:
20060724, make check-target-libstdc++
1145.687u 137.804s 23:13.98
I had a conversation with Russell King about asm() and historical problems
with it. He told me that in old versions of GCC, it was necessary to either
clobber conds or else use %?; otherwise GCC could mistakenly omit a branch
around the inline asm.
When (around GCC 3.0) we started to use final.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 13:23 ---
It might not have doubled but one testcase that was added might have been
always slow. We really need one testcase that has slowed down or one testcase
that has always been slow that was added.
--
pinskia at
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 13:26 ---
configure: error: /bin/sh '/lhome/gcc/gcc-4.1.1/libjava/classpath/configure'
You forgot to do CONFIG_SHELL=/bin/ksh as mentioned by:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
The Solaris 2 /bin/sh will
--- Comment #4 from steven at gcc dot gnu dot org 2006-08-28 13:59 ---
From the hammer branch for AMD64:
.globl f
.type f, @function
f:
.LFB4:
testl %edi, %edi
movl%esi, %eax
jne .L3
movl%edx, %esi
movl%edx, %eax
.L3:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-28 14:37 ---
(In reply to comment #4)
So not all gcc3 releases do so well. Are there GCC releases that optimize the
two functions to identical code?
Yes (FSF) 3.2.3.
.globl f
.type f,@function
f:
movl
gfortran reports the following error:
call create()
1
Error: Generic subroutine 'create' at (1) is not an intrinsic subroutine
when trying to compile the following code:
module A
private
interface create
module procedure create1
end interface
public ::
The following code:
subroutine cycle
implicit none
integer :: nsos, isym, nsym = 10
integer :: norb(10)
isym_: do isym = 1, nsym
nsos = norb(isym)
if (nsos==0) cycle isym_
enddo isym_
end subroutine
causes this compile time error:
if (nsos==0) cycle isym_
--- Comment #11 from clemens dot koller at anagramm dot de 2006-08-28
15:37 ---
Same bug occures with 4.1.1 too, verified on an x86 and ppc host, cross
compiling for Atmel AVR:
configure --target=avr --with-dwarf2
triggers the bug.
--
clemens dot koller at anagramm dot de changed:
--- Comment #16 from sje at cup dot hp dot com 2006-08-28 16:07 ---
Yes, I did some performance measurements with SPEC2000. Allowing any (symbol +
offset) resulted in slightly slower code overall, allowing no (symbol + offset)
resulted in slightly faster code overall. I will be
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1305
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-28 16:54 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #4 from aph at gcc dot gnu dot org 2006-08-28 16:55 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-28 16:56 ---
Should be fixed on trunk.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aph at gcc dot gnu dot org 2006-08-28 16:57 ---
This will be fixed with ecj.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from kazu at gcc dot gnu dot org 2006-08-28 17:18 ---
Subject: Bug 26632
Author: kazu
Date: Mon Aug 28 17:18:29 2006
New Revision: 116510
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116510
Log:
gcc/
PR middle-end/26632
* convert.c
--- Comment #50 from amacleod at redhat dot com 2006-08-28 17:18 ---
Subject: Bug 28071
Author: amacleod
Date: Mon Aug 28 17:18:33 2006
New Revision: 116511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116511
Log:
revert 116257 which is the rewrite_liverange_info patch, so be
--- Comment #27 from kazu at gcc dot gnu dot org 2006-08-28 17:28 ---
The real fix it to issue uninitialized warnings before the inliner kicks in
but after we go into SSA, which is impossible until we start doing early SSA.
As Nathan suggests, this caveat should be mentioned in the
--- Comment #51 from amacleod at redhat dot com 2006-08-28 17:37 ---
Huh. I didn't realize bugzilla scanned the entire checkin message looking for
bug numbers This has been checked in on a branch, so you can ignore the
preceeding note's commentary. it's just a note to myself.
--
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-28 17:55 ---
This is my screw.
*** This bug has been marked as a duplicate of 28866 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2006-08-28 17:55 ---
*** Bug 28874 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org
The above sequence of warning flags causes unused-parameters to be reported,
while one expects it to not. The fact that -Wextra and -Wall together
magically turn unused-parameter on is shadowing the effect of the explicit
-Wno-unused-parameter. It took me quite a while to figure that out.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 19:40 ---
I don't think this is a bug since the behavior is documented:
In order to get a warning about an unused function parameter, you must either
specify `-Wextra -Wunused' (note that `-Wall' implies `-Wunused'), or
--- Comment #2 from bob at digilink dot net 2006-08-28 19:45 ---
I'm sorry - I thought I had looked through all of the Solaris build issues but
there it is plain as day - If it was a snake it would have bit me!
Thank you for pointing me in the right direction and for your patience.
There are some really useful warnings enabled by -Wextra that don't have
separate -W enablers. They should, as not everyone likes all the noise that
-Wextra generates.
These two are the ones I failed to find how to enable other than by using
-Wextra:
warning: comparison of unsigned expression =
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-08-28 20:18 ---
Subject: Bug 23773
Author: bkoz
Date: Mon Aug 28 20:18:22 2006
New Revision: 116527
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116527
Log:
2006-08-28 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 20:33 ---
*** This bug has been marked as a duplicate of 7651 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-28 20:33 ---
*** Bug 28876 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-28 20:36 ---
(In reply to comment #6)
The log message and the ChangeLog entry don't mention it, but this patch also
modifies gcc/dwarf2out.c.
It was backed out right after the commit:
--- Comment #20 from janis at gcc dot gnu dot org 2006-08-28 20:42 ---
Subject: Bug 25259
Author: janis
Date: Mon Aug 28 20:42:12 2006
New Revision: 116528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116528
Log:
Backport from mainline (part of r198241)
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-08-28 20:44 ---
(In reply to comment #3)
Created an attachment (id=12037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12037action=view) [edit]
patch
It looks like we should bite the bullet and let cgraph code to output
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-28 21:03 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=110017
r110017 | mmitchel | 2006-01-20 03:07:58 + (Fri, 20 Jan 2006)
--
janis at gcc dot gnu dot org
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-08-28 21:15
---
Subject: Bug 28411
Author: rakdver
Date: Mon Aug 28 21:15:19 2006
New Revision: 116529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116529
Log:
PR tree-optimization/28411
* double-int.c
--- Comment #7 from h dot mth at web dot de 2006-08-28 21:45 ---
I stored my broken ecj-3.2.jar here:
http://geki.ath.cx/hacks/ecj.jar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-28 22:14 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=116409
r116409 | nathan | 2006-08-25 16:56:07 + (Fri, 25 Aug 2006)
--
janis at gcc dot gnu dot org
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-28 22:15 ---
The problem lies in resolve.c (resolve_generic_s):1623
On the face of it,
if (sym-ns-parent != NULL !sym-attr.use_assoc)
seems to be wrong.
if (sym-ns-parent != NULL) fixes the problem and is regtesting as I
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-28 22:22 ---
The problem lies in resolve.c (resolve_generic_s):1623
yes, definitely. resolve_generic_f is not so prissy about use association
and has a somewhat different structure. If I were to transport this to
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2006-08-28 22:15:42 |2006-08-28
This doesn't work on my apple gcc. If you inspect with -v, it compiles each
file in turn and writes to file.o, each file overwriting the one before it,
rather than combining the three .c files into one .o.
I can think of some pretty good reasons to do this, including cross
compilation-unit
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-28 22:35
---
Subject: Bug 28860
Author: reichelt
Date: Mon Aug 28 22:34:55 2006
New Revision: 116541
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116541
Log:
PR c++/28860
* cp-tree.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 22:49 ---
This was a bug in 4.0.0-4.0.2, it was fixed for 4.0.3 by me never the less.
To get IMA, you need -combine.
*** This bug has been marked as a duplicate of 22544 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-28 22:49
---
*** Bug 28877 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-28 22:50 ---
PS please report Apple GCC bugs to Apple first and if you want to report a GCC
bug to the FSF, please test on the branch (and/or the latest release).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28877
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-28 22:51
---
Subject: Bug 28860
Author: reichelt
Date: Mon Aug 28 22:51:17 2006
New Revision: 116543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116543
Log:
PR c++/28860
* cp-tree.h
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-28 22:58 ---
I can confirm that the latest regression is from r112408.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-28 23:12
---
Subject: Bug 28860
Author: reichelt
Date: Mon Aug 28 23:12:32 2006
New Revision: 116544
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116544
Log:
PR c++/28860
* cp-tree.h
--- Comment #3 from iano at apple dot com 2006-08-28 23:13 ---
Thanks for fixing it Andrew. I can confirm that -combine works. Hopefully Apple
will get around to updating to 4.0.3 one of these days.
...and really, you should be thrilled to get duplicate bug reports! They are
sooo much
1 - 100 of 120 matches
Mail list logo
