--- 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=17320&action=view)
ai2.ii.bz2
Original (almost) unreduced testcase. The:
warning: dereferencing pointer '' does break strict-alias
--- 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=17321&action=view)
ai3.ii.bz2
Slightly reduced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
#include
#include
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:~$ gcc -o test te
--- 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=17322&action=view)
glibmm.ii.bz2
Testcase from another package. Similarly to the ai* (wesnoth-1.5), in this
case also some warning
--- 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 fo
--- 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:
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 n
--- 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:
W
--- 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 clas
--- 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...
--
ht
--- 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 fr
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" > wrote:
/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-options "-O2 -mtune=cell -mminimal-toc" { target { powerpc
--- 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 P
--- 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=17323&action=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 the
--- 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 set
--- 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=17324&action=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
enable
--- 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
--- 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
wrote:
>
>
> --- Comment #12 from hubicka at ucw dot cz 2009-02-18 01:42 ---
> Subjec
--- 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 bran
--- 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?
--
http://gcc.gnu.org/bug
--- 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 tu
--- 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 s
--- 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 ra
The following code gives wrong result with -O2 and above :
% gcc -O0 -o example example.c && ./example
1
% gcc -O2 -o example example.c && ./example
0
The bug is triggered on i486 platform, with gcc 4.3.2 but not with gcc 4.1.2.
#include
int main(void) {
volatile int y;
int x;
y =
--- 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 #12 from ebotcazou at gcc dot gnu dot org 2009-02-18 14:38
---
> I believe that warning is turned on for C ObjC C++ ObjC++ only.
Wrong.
spgn_numerics.ads: In function 'Test_Gip_Stat':
spgn_numerics.ads:25: note: The ABI of passing union with long double has
changed in GCC
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-02-18 14:51
---
Created an attachment (id=17325)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17325&action=view)
Ada testcase
(botca...@red) ~ $ gcc -S p.ads
p.ads:16: note: The ABI of passing union with long double has
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-18
14:56 ---
Submitted patch to gcc-patches...
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00831.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38165
--- 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
--
http://gcc.gnu.org/bu
--- Comment #4 from eric dot weddington at atmel dot com 2009-02-18 15:19
---
Fail on 4.3.2 with -O1, success with -O[023s].
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-18 15:50 ---
For sysv/x86-64, XFmode is 16byte with 16byte alignment. It is
passed in memory and returned in in %st0/%st1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
This is seen on the version of avr-gcc 4.3.3 that gets built by the script that
comes with FemtoOS 0.88.
I'm compiling like this:
avr-gcc -mmcu=atmega128 -O0 small_preprocessed.c -o small.elf
And observing the result of a run like this:
java -server avrora.Main -platform=mica2 -simulation=s
--- 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=17326&action=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
(sometim
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 poin
--
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=17325&action=view) [edit]
> Ada testcase
>
> (botca...@red) ~ $ gcc -S p.ads
> p.ads:16: note: The A
--- 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
Assigne
--- 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, FUNCTION
--- 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 t
--- 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
rget: 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
--- 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; i
--- 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 P
--
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 libra
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-18 18:38 ---
const fptr_t f = inlinable;
extfunc(&f);
f();
extfunc can change the value of f so this is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-18 18:46 ---
It works for me with:
GNU C++ (GCC) version 4.4.0 20081229 (experimental) [trunk revision 142951]
(i386-apple-darwin8.11.1)
compiled by GNU C version 4.4.0 20081229 (experimental) [trunk revision
142951], GMP
--- 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 4.2.
--- 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
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-18 19:50
---
The updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00871.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-18 19:56 ---
I'm sure it is somehow possible, maybe we can use scev_probably_wraps_p
in simple_iv. I will check that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
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 opti
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 20:19 ---
It is caused by revision 143502 on trunk:
http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00515.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--
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=gcc&view=rev&rev=144270
Log:
PR target/39179
* tree-ssa-ccp.c (get_symbol_con
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
--- 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 because
--- 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=17327&action=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=gcc&view=rev&rev=144272
Log:
2009-02-18 H.J. Lu
PR target/39224
* config/i386
--- 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 c
On Mon, Feb 16, 2009 at 7:29 PM, e211 wrote:
>
> //The following code works and there is no way it should. Seems like a bug
> someone put in on purpose
>
> #include
> using namespace std;
>
> void swap(int *x, int *y)
> {
>int temp;
>temp = *x;
>*x = *y;
>*y = tem
--- 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 compile
1 - 100 of 130 matches
Mail list logo
