--- Comment #2 from ktietz at gcc dot gnu dot org 2009-02-18 08:18 ---
(In reply to comment #1)
I think long double on w64 is the same as double. I am not sure if
gcc.dg/callabi/func-1.c is a valid test.
the long double is supported as 96-bit floating point for gcc. This isn't as
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-18 08:20 ---
Unfortunately I'm still seeing these warnings on the original unreduced
testcase. I'll attach them momentarily.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jakub at gcc dot gnu dot org 2009-02-18 08:23 ---
Created an attachment (id=17320)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17320action=view)
ai2.ii.bz2
Original (almost) unreduced testcase. The:
warning: dereferencing pointer 'anonymous' does break
--- Comment #13 from jakub at gcc dot gnu dot org 2009-02-18 08:24 ---
Created an attachment (id=17321)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17321action=view)
ai3.ii.bz2
Slightly reduced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
#include stdio.h
#include math.h
int main()
{
double a= 10.0;
double b= 1e+308;
printf(%d %d %d\n, isinf(a*b), __builtin_isinf(a*b), __isinf(a*b));
return 0;
}
mtay...@drizzle-dev:~$ gcc -o test test.c
mtay...@drizzle-dev:~$ ./test
0 0 1
mtay...@drizzle-dev:~$
--- Comment #14 from jakub at gcc dot gnu dot org 2009-02-18 08:31 ---
Created an attachment (id=17322)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17322action=view)
glibmm.ii.bz2
Testcase from another package. Similarly to the ai* (wesnoth-1.5), in this
case also some warnings
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-02-18 08:47 ---
(In reply to comment #2)
I am verifying it at the moment for w64 target, if we have here same issues.
Yes, on w64 targets we have the same issue. By adding print methods, it seems
that the return value of the
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-18 08:54 ---
Yeah, with ulimit you can always pick some limit almost any change might go
over. As a bug should be only considered if memory usage increases a lot,
daily tiny increases and decreases in memory usage aren't a bug.
--- Comment #23 from rguenther at suse dot de 2009-02-18 09:34 ---
Subject: Re: loop number of iterations analysis
not working
On Wed, 18 Feb 2009, rakdver at kam dot mff dot cuni dot cz wrote:
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2009-02-18
04:11
If 'warn' after PRINT is removed, the snippet is accepted as is, without
further warning. I'm not sure if this kind of thing is legal to begin with, but
I'd at least expect a warning for both truncated lines.
$ cat trunc.f
PRINT *, MIN(1
--- Comment #1 from ubizjak at gmail dot com 2009-02-18 09:47 ---
Looking into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-02-18 09:51
---
Please make sure the warning is issued only for appropriate languages (it is
not
needed in Ada for example and the wording doesn't make sense). TIA.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-18 10:03 ---
Please fill out GCC version this bug is reported against.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-18 10:11 ---
It works for me with the release-checking built 4.3.3 release (as well as
4.3.0, 4.3.1 and 4.3.2). With the branch r143959 and checking enabled it gives
test.cc:6: internal compiler error: tree check: expected
--- Comment #4 from aj at gcc dot gnu dot org 2009-02-18 10:17 ---
Increasing ulimit from 100 to 110 (10 %!) did not help, increasing it
to 120 helped.
So, we have now hit quite some increase of memory usage with just this single
commit and not just a few bytes...
--
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-18 10:20 ---
I think that also happens if one does not have a procedure call but simply have
a succeeding continuation line, e.g.:
print *, min(1,2) [...] some long line
, 2
And it seems to happen also with
This is mostly likely due to my no micro code patch. I see what causes
it tommorow.
Sent from my iPhone
On Feb 17, 2009, at 11:55 PM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=cell
--- Comment #1 from pinskia at gmail dot com 2009-02-18 10:30 ---
Subject: Re: New: [4.4 Regression] gcc_assert (verify_initial_elim_offsets
()); ICE
This is mostly likely due to my no micro code patch. I see what causes
it tommorow.
Sent from my iPhone
On Feb 17, 2009, at 11:55
--- Comment #2 from ubizjak at gmail dot com 2009-02-18 10:33 ---
Created an attachment (id=17323)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17323action=view)
patch
Patch currently in testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39228
Consider the following snippet:
implicit none
integer, pointer :: p
print *,associated(p)
end
This is actually invalid and should probably trigger a runtime error. Section
13.7.13 of the Fortran 2003 standard says that the pointer argument of
ASSOCIATED should not be undefined, which it is in
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-02-18 10:45 ---
ok, I found the issue, which causes here the problem.
The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack
variable as 96 bits, but the upper 32-bits (which have to be zero initialized)
aren't
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-18 10:46 ---
But not on the same source, but different one (insn-recog.c grew because of
that change).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-18 10:54
---
*sigh*
Looks like PR39074. I chickened out to backport this from a-i branch... I'll
have a second look.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
--- Comment #3 from christi at uni-hd dot de 2009-02-18 11:10 ---
Created an attachment (id=17324)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17324action=view)
preprocessed test.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
--- Comment #3 from stewart at flamingspork dot com 2009-02-18 11:20
---
To implement a work around for us, I'm proposing the patch below.
- the tmp2 being volatile was for who knows what reason (old code)
- The check should (on c99 systems or those with the right compile options
--- Comment #5 from ubizjak at gmail dot com 2009-02-18 12:06 ---
(In reply to comment #4)
ok, I found the issue, which causes here the problem.
The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack
XFmode
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-02-18 12:11 ---
(In reply to comment #5)
(In reply to comment #4)
ok, I found the issue, which causes here the problem.
The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack
XFmode
right, sorry I meant
--- Comment #13 from dnovillo at google dot com 2009-02-18 12:26 ---
Subject: Re: LTO and -fwhole-program do not play
along well
On Tue, Feb 17, 2009 at 20:42, hubicka at ucw dot cz
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #12 from hubicka at ucw dot cz 2009-02-18
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-18 12:28 ---
Yeah. Unlike anddi3_internal3_mc insn, anddi3_internal3_nomc only has an
alternative with t for the and64_2_operand that is not slightly disparaged
(?s), so for masks that match mask_operand or mask64_operand reload
--- Comment #4 from jeremy at jeremybennett dot com 2009-02-18 12:28
---
Thanks for the advice. I had not realized that ccache was a separate program.
I've taken up the issue with them.
Jeremy
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39220
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-18 12:56
---
Ok, a backported patch fixes all three new testcases. I was avoiding the
backport to avoid late performance and/or compile-time regressions, so I'll
give the patch (and one accompanied change that went to the
--- Comment #23 from bonzini at gnu dot org 2009-02-18 13:02 ---
Gcc doesn't know/remember
movlS(,%rax,4), %eax
will zero extend to 64bit. I don't know you can touch only the lower
32bit bits.
This could be fixed by LOAD_EXTEND_OP, right?
--
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-18 13:13 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-18 13:15 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-18 14:08
---
(In reply to comment #10)
Please make sure the warning is issued only for appropriate languages (it is
not
needed in Ada for example and the wording doesn't make sense). TIA.
I believe that warning is
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 14:13 ---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #4)
ok, I found the issue, which causes here the problem.
The x86_64 abi returns TFmode in rax,edx which is stored in aligned stack
--- Comment #4 from ubizjak at gmail dot com 2009-02-18 14:15 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00825.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-18 14:23 ---
(In reply to comment #7)
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #4)
ok, I found the issue, which causes here the problem.
The x86_64 abi returns TFmode in rax,edx which
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-18 14:37 ---
gcc -o t t.c -O2 -Wstrict-overflow
t.c: In function main:
t.c:13: warning: assuming signed overflow does not occur when simplifying
conditional to constant
negating signed 0x8000 invokes undefined behavior.
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-18 15:10
---
(In reply to comment #12)
I believe that warning is turned on for C ObjC C++ ObjC++ only.
Wrong.
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00834.html
--
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-18 16:41 ---
I'm not sure if this kind of thing is legal to begin with
Well, the Fortran standard only has:
Free form: If a line consists entirely of characters of default kind (4.4.4),
it may contain at most 132 characters.
--- Comment #1 from regehr at cs dot utah dot edu 2009-02-18 16:41 ---
Created an attachment (id=17326)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17326action=view)
failure-inducing C program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
--- Comment #6 from sebor at roguewave dot com 2009-02-18 16:50 ---
(In reply to comment #5)
Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their types
extern void abort (void);
__attribute__((noinline)) void
foo (void *p)
{
long l = (long) p;
if (l 0 || l 6)
abort ();
}
int
main ()
{
int i;
for (i = 6; i = 0; i--)
foo ((void *) (long) i);
return 0;
}
is miscompiled (into endless loop). First ivopts decides to use a
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-18 17:24 ---
Caused by PR31358.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-18 17:28 ---
This is actually invalid
Yes, but this is a requirement to the program(mer) not to the compiler.
and should probably trigger a runtime error.
Yes, but only with some checking option, otherwise it really gets too
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-18 17:32 ---
The other bug is PR 29616.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230
--- Comment #15 from hjl dot tools at gmail dot com 2009-02-18 17:43
---
(In reply to comment #13)
Created an attachment (id=17325)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17325action=view) [edit]
Ada testcase
(botca...@red) ~ $ gcc -S p.ads
p.ads:16: note: The ABI of
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-18 17:47 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from jason at gcc dot gnu dot org 2009-02-18 17:47 ---
(In reply to comment #19)
I suppose it's a question of what module means.
module is used in a lot of different ways, but this usage definitely refers
to the current translation unit:
/* In a VAR_DECL,
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-18 17:50 ---
Confirmed on x86_64 with -O2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC
--- Comment #21 from jason at gcc dot gnu dot org 2009-02-18 17:51 ---
OTOH, the use of visibility in default_binds_local_p is also wrong under this
interpretation...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --program-suffix=-4.4
--enable-languages=c
Thread model: posix
gcc version 4.4.0 20090218 (experimental) (GCC)
--
Summary: Call to constant function pointer not inlined
Product: gcc
Version: 4.4.0
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-18 17:53 ---
This one also fails on i?86-*-*:
extern void abort (void);
__attribute__((noinline)) void
foo (void *p)
{
long l = (long) p;
if (l 0 || l 6)
abort ();
}
int
main ()
{
short i;
for (i = 6; i = 0;
--- Comment #22 from jason at gcc dot gnu dot org 2009-02-18 18:06 ---
Seems like we already had this discussion last year, starting at
http://gcc.gnu.org/ml/gcc/2007-06/msg00848.html
The conclusion there was that binds_local_p means binds to this
executable/shared library, and the PE
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #23 from jason at gcc dot gnu dot org 2009-02-18 18:31 ---
...and then of course there's the actual documentation:
TARGET_BINDS_LOCAL_P (tree exp)
Returns true if exp names an object for which name resolution
rules must resolve to the current ``module'' (dynamic shared
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-18 18:46 ---
And:
GNU C++ (GCC) version 4.4.0 20090116 (experimental) [trunk revision 143448]
(powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090116 (experimental) [trunk revision
143448], GMP version
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-18 18:47 ---
This patch fixes it, with unknown side-effects. It should be ok for
the common sizetype extensions due to POINTER_PLUS_EXPR (sizetype is
unsigned for sane languages).
Index: tree-scalar-evolution.c
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-18 18:47 ---
And in the release of 4.3.2 with checking turned on.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-18 18:53
---
The problem is callee returns long double via a pointer to a structure.
But caller thinks callee returns long double in rax/edx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-18 18:56 ---
Would it be possible for known loop bounds to still use pointer etc. ivopts if
we can ensure the overflow doesn't happen on that interval (+-1)? Say if the
same testcase goes for (i = 16; i = 10; i--) instead of for
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-18 19:22
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00870.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-18 19:34 ---
Hmm, for the PS3 toolchain, I think I just removed anddi3_internal3_mc.
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-18 19:40 ---
You mean anddi3_internal3_nomc, right? If so, I guess anddi3_internal2_nomc
should be removed too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-18 19:41 ---
(In reply to comment #4)
You mean anddi3_internal3_nomc, right? If so, I guess anddi3_internal2_nomc
should be removed too.
I will have to look at what I did, I know I ran into a case where a constant
was being
get_simple_loop_desc uses the XNEW macro to allocate the new loop description,
thus the memory is not initialized.
At least the desc-infinite field thus can remain uninitialized when the
function returns.
As long as the optimizers only punt on infinity that can result in
pseudo-random
missed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail|4.3.4 |4.3.4 4.4.0
Known to work|4.4.0 4.3.2 |4.3.2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-18 20:57 ---
Such patch would be obvious and a minor change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39235
--- Comment #24 from jason at gcc dot gnu dot org 2009-02-18 21:01 ---
Subject: Bug 39179
Author: jason
Date: Wed Feb 18 21:01:03 2009
New Revision: 144270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144270
Log:
PR target/39179
* tree-ssa-ccp.c
G++ uses TREE_STATIC to mean will be written out statically somewhere rather
than write out statically in this TU; it should be set on VAR_DECLs that also
have DECL_EXTERNAL set.
Historically we've set DECL_EXTERNAL on anything that we weren't yet sure
whether or not we were going to write out in
--- Comment #25 from jason at gcc dot gnu dot org 2009-02-18 21:09 ---
Fixed. The C++ static/extern issue has been added as PR 39236.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #24 from hjl dot tools at gmail dot com 2009-02-18 21:24
---
I tried:
--- config/i386/i386.h.zero 2009-02-18 08:42:40.0 -0800
+++ config/i386/i386.h 2009-02-18 13:16:26.0 -0800
@@ -1940,6 +1940,11 @@ do {
--- Comment #25 from hjl dot tools at gmail dot com 2009-02-18 21:31
---
All 32bit load insns are zero extended to 64bit, not just move.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
Hello,
We use a unit testing framework which overloads operator new and operator
delete to track memory allocations and detect leaks. According to it, vector's
push_back method allocates memory through operator new but does not release it
through operator delete.
I am not sure if this is
--- Comment #1 from caroline dot rioux at ca dot ibm dot com 2009-02-18
21:39 ---
Created an attachment (id=17327)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17327action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
--- Comment #13 from hjl at gcc dot gnu dot org 2009-02-18 21:40 ---
Subject: Bug 39224
Author: hjl
Date: Wed Feb 18 21:40:08 2009
New Revision: 144272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144272
Log:
2009-02-18 H.J. Lu hongjiu...@intel.com
PR target/39224
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-18 21:45 ---
Fixed in 4.1.0 as mentioned already. 3.3.x is no longer maintained and any bug
that is reported against that old version is most likely not going to be ever
fixed.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #17 from danglin at gcc dot gnu dot org 2009-02-18 21:54
---
Configuring with --disable-stage-checking, I see the following for cc1:
-bash-3.2$ size cc1
text data bss dechex filename
28977798 496932 623152 300978821cb41da
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-18 21:55 ---
We need a preprocessed source or at least a self contained example. It might
be the case you don't use the correct barriers or atomics when doing updates of
a global variable.
--
pinskia at gcc dot gnu dot org
On Mon, Feb 16, 2009 at 7:29 PM, e211 e...@hotmail.com wrote:
//The following code works and there is no way it should. Seems like a bug
someone put in on purpose
#include iostream
using namespace std;
void swap(int *x, int *y)
{
int temp;
temp = *x;
*x = *y;
--- Comment #3 from caroline dot rioux at ca dot ibm dot com 2009-02-18
22:02 ---
(In reply to comment #2)
Fixed in 4.1.0 as mentioned already. 3.3.x is no longer maintained and any
bug
that is reported against that old version is most likely not going to be ever
fixed.
Ok
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-18 22:06 ---
(In reply to comment #3)
Ok thanks for your input. Was this explicitly fixed or a result of other
framework changes? Is there any way a patch exists and could be applied?
Off hand I don't know.
I ask because
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2009-02-18 22:11
---
Fixed. The C++ static/extern issue has been added as PR 39236.
You have installed a lot more things than what's described in the ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #5 from caroline dot rioux at ca dot ibm dot com 2009-02-18
22:15 ---
(In reply to comment #4)
Nope, only currently 4.2 and above are being maintained. Is there a reason
why
you unlikely to move to 4.x in the short term?
We have a big code base and changing compilers
--- Comment #2 from dpirch at gmail dot com 2009-02-18 22:16 ---
extfunc cannot change the value of f, it would lead to undefined behavior.
If an attempt is made to modify an object defined with a const-qualified type
through use of an lvalue with non-const-qualified type, the behavior
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-18 22:19 ---
Subject: Bug 38166
Author: janis
Date: Wed Feb 18 22:19:26 2009
New Revision: 144274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144274
Log:
2009-02-18 Jack Howarth howa...@bromo.med.uc.edu
PR
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-18 23:18 ---
Subject: Bug 38165
Author: janis
Date: Wed Feb 18 23:17:56 2009
New Revision: 144277
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144277
Log:
2009-02-18 Jack Howarth howa...@bromo.med.uc.edu
PR
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-18 23:42
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 23:44 ---
(In reply to comment #3)
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00790.html
Jason, can you take a look at this one line fix? Thanks.
--
hjl dot tools at gmail dot com changed:
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-18 23:45 ---
(In reply to comment #2)
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00714.html
Jason, Richard, can you review this wrong-code fix? Thanks.
--
hjl dot tools at gmail dot com changed:
--- Comment #27 from jason at gcc dot gnu dot org 2009-02-19 01:12 ---
I reverted the mistaken checkins a few seconds later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-19 01:58 ---
Subject: Bug 39219
Author: hjl
Date: Thu Feb 19 01:58:15 2009
New Revision: 144284
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144284
Log:
gcc/cp
2009-02-18 H.J. Lu hongjiu...@intel.com
PR
/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [trunk revision 144279] (GCC)
# gmake
...
Making all in include
gmake[4]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/include
--- Comment #1 from rob1weld at aol dot com 2009-02-19 02:21 ---
New warning different GCC executable was just 'xgcc' instead of 'g++'.
Next error in 'extc++.h.gch/O2g.gch' is fixed by:
/usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc
-B/usr/share/src/gcc_build/./gcc -nostdinc++
--- Comment #2 from rob1weld at aol dot com 2009-02-19 02:30 ---
That worked.
The build continues until it fails here:
# gmake
(5 minutes)
...
Making all in src
gmake[4]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src'
...
-DPIC -o
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-19
02:31 ---
Fixed on current gcc trunk.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
1 - 100 of 118 matches
Mail list logo
