--- Comment #2 from jsun at junsun dot net 2009-05-09 06:04 ---
We have confirmed that this problem still exists in gcc 4.3.3.
It appears other than this problem, XIP on ARM actually works. XIP on ARM also
worked fine with gcc 3.x, with "-fpic -msingle-pic-base" compile option.
--
On Linux/ia32, revision 147294:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html
caused
FAIL:
/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe
execution -
/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe
FAIL: g++.dg/opt/
--- Comment #6 from wilson at gcc dot gnu dot org 2009-05-09 01:21 ---
It looks like this was fixed by Michael Matz here:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
This patch was added to gcc-4.3, and the gcc-4.2 branch is closed, so I think
this bug should be closed resol
--- Comment #11 from dougkwan at google dot com 2009-05-09 01:21 ---
We saw this also in gcc-4.3.1 on target arm-none-eabi.
--
dougkwan at google dot com changed:
What|Removed |Added
-
--- Comment #2 from scovich at gmail dot com 2009-05-08 23:24 ---
Sorry to bring this back up, but I'm not sure if comments show up in a
meaningful way on closed bugs...
1. where does is it documented that inline asm can't change control flow? I
can't find it in the info pages, nor anyw
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-08 23:15 ---
Another difference between C and C++:
[...@gnu-6 tmp]$ cat bad.i
typedef int INT2 __attribute__((deprecated));
int f5(INT2 x);
int f6(INT2 x) __attribute__((deprecated));
[...@gnu-6 tmp]$ gcc -S bad.i
bad.i:2: warni
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 22:52 ---
This is by design, first inline-asm is not allowed to change control flow.
Second labels can be moved if they are not used normally in the program. In
this case they are not used normally. Addresses of labels are o
Somewhat to my surprise, the gcc accepts the following inline asm syntax:
asm("jmp %0" : : "i"(&&some_label));
The output is what you'd expect: assuming some_label (in C/C++) is associated
with the assembler label .LLBF4 gives:
jmp .LLBF4
Unfortunately, the optimizer plays havoc with things by
--- Comment #10 from meissner at gcc dot gnu dot org 2009-05-08 22:39
---
Subject: Bug 40049
Author: meissner
Date: Fri May 8 22:38:49 2009
New Revision: 147298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147298
Log:
Fix PR 40049
Added:
trunk/gcc/testsuite/gcc.dg/vect/
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 22:21 ---
*** This bug has been marked as a duplicate of 17729 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-08 22:21
---
*** Bug 40077 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
C++ compiler will issue the duplicated deprecated message:
[...@gnu-6 gcc]$ cat /tmp/fun.i
int f1 () __attribute__((deprecated));
int
foo ()
{
return f1 ();
}
[...@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/fun.i
/tmp/fun.i: In function foo:
/tmp/fun.i:6: warning: f1 is deprecated (declared at /tmp/f
--- Comment #3 from ian at airs dot com 2009-05-08 22:19 ---
Yeah, in C you can define a struct type in a type cast and then use it later.
Cool stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-08 21:51 ---
Oh, types are valid to be defined in casts in C. You did not mention that in
the bug report so I thought you could not define a type in C either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 21:41 ---
But is defining a new type in a compound literal legal for C99?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
This is invalid C++:
struct s1 { int i; } *p;
int i = ((struct s2 { int j; } *)p)->j;
foo.cc:2: error: types may not be defined in casts
By analogy, this should be invalid C++:
int i = (struct s3 { int j; }) { 1 }.j;
Currently g++ accepts it. Compound literals are an extension to C++, so ther
deprecated("xxx") doesn't work on function parameter with C++:
[...@gnu-6 gcc]$ cat /tmp/foo.i
typedef int INT2 __attribute__((deprecated("Please avoid INT2")));
int f5(INT2 x);
[...@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/foo.i
/tmp/foo.i:2: warning: INT2 is deprecated: Please avoid INT2
[...@gnu-6 gc
--- Comment #7 from hjl dot tools at gmail dot com 2009-05-08 21:07 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-08 21:00 ---
Created an attachment (id=17833)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17833&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-08 20:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-05-08 20:52
---
Debugging cc1plus for this slightly reduced program:
template
struct x
{
protected:
typedef int type;
};
template
struct y : public x
{
typename x::type z;
};
template<>
struct y : public x
{
t
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-08 20:41 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
GCC target triplet||x86_64-*-
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-08
20:34 ---
Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
> Interesting you don't hit the bug I described in PR 40031.
I tested the following in the regression search:
146971 bad
146908 b
/lucier/gcc/mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline --enable-languages=c
--enable-gather-detailed-mem-stats
Thread model: posix
gcc version 4.5.0 20090508 (experimental) [trunk revision 147288] (GCC)
on the compiler.i test case with
/pkgs/gcc-mainline/bin/gcc -save
--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2009-05-08
20:16 ---
Created an attachment (id=17832)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17832&action=view)
Preprocessed source of source that triggers ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
I;m running gcc-4.4.0 (built with default optimization flags, but with
additional optimizations) and was testing it on ocrad-0.18 (admittedly with
lots of optimization): I get
g++ -march=pentium4 -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops
-fomit-frame-pointer -floop-interchange -floop-s
--- Comment #5 from hubicka at ucw dot cz 2009-05-08 19:44 ---
Subject: Re: [4.5 Regression] verify_eh_tree failed with -O2
This is very sick side case of updating prev_try pointer in
duplicate_eh_edges. I think it is clear that maintaining prev_try
pointer just to slightly speed up t
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-05-08 19:35 ---
(In reply to comment #8)
> Introduced in revision 146894:
Interesting you don't hit the bug I described in PR 40031.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
--- Comment #3 from gbrammer at gmx dot de 2009-05-08 19:17 ---
Well, I am sure that it shouldn't be created, but rereading the spec
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html 12.8) I
noticed that this bug is not in g++, but by design.
I had hoped that rvalue ref
--- Comment #3 from tobi at gcc dot gnu dot org 2009-05-08 18:53 ---
Note that the C-like equivalent doesn't warn (at least with g++ 4.1.2):
$ cat user/t.cc
namespace {
struct {
} t;
}
static struct {
} s;
$ g++ -c user/t.cc
user/t.cc:3: warning: non-local variable '::
::t' uses ano
--- Comment #6 from hjl at gcc dot gnu dot org 2009-05-08 18:45 ---
Subject: Bug 36892
Author: hjl
Date: Fri May 8 18:44:50 2009
New Revision: 147293
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147293
Log:
gcc/
2009-05-08 H.J. Lu
Andrew Morrow
PR c
--- Comment #8 from danglin at gcc dot gnu dot org 2009-05-08 18:21 ---
Introduced in revision 146894:
2009-04-28 Andrew Pinski
PR target/39929
* config/darwin.c (machopic_gen_offset): Check
currently_expanding_to_rtl if current_ir_type returns IR_GIMPLE.
--- Comment #2 from laurent at guerby dot net 2009-05-08 18:15 ---
The Ada test was added by Eric Botcazou:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01204.html
<<
The predictive commoning pass performs load hoisting on an expression that can
throw, thus breaking the CFG; of course
--- Comment #1 from laurent at guerby dot net 2009-05-08 18:08 ---
According to line information the assert that fails is about aliasing:
/* If accesses through a pointer to vectype do not alias the original
memory reference we have a problem. This should never h
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-08
16:59 ---
Created an attachment (id=17827)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17827&action=view)
test case
This code is an example of the code that generates sub-optimal code.
--
http://gcc.
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2009-05-08
17:06 ---
Created an attachment (id=17831)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17831&action=view)
Vectorizer verbose output
This is the output from the Powerpc compiler with -fdump-tree-vect
-ftre
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-05-08
17:04 ---
Created an attachment (id=17830)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17830&action=view)
X86_64 example code
This code was compiled with an x86_64 compiler with the -O3 -msse3 options.
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-05-08
17:03 ---
Created an attachment (id=17829)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17829&action=view)
Powerpc example code
This code was compiled with -O3 -maltivec.
--
http://gcc.gnu.org/bugzill
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-08
17:02 ---
Created an attachment (id=17828)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17828&action=view)
Replacement test case that doesn't need -DTYPE to show the bug
Replacement test case.
--
meiss
On machines like the x86_64/i386 with -msse2 option or powerpc with the
-maltivec option that support vector 8-bit/16-bit shift instructions, GCC
generates suboptimal code for variable shifts. Rather than generate the native
instruction, the compiler converts the vector to V4SI vector, does the sh
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-05-08 16:21 ---
*** Bug 40066 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 16:21 ---
see 15.3 P 9:
If no matching handler is found in a program, the function terminate() is
called; whether or not the
stack is unwound before this call to terminate() is implemenation-defined
(15.5.1)
So we define it
--- Comment #11 from kargl at gcc dot gnu dot org 2009-05-08 16:18 ---
(In reply to comment #10)
> When I run the fortran code: print *, precision(1.e0), digits(1.e0)
> I get: 6,24
Read Goldberg's paper.
I suspect you have either a rounding issue
(hint, see Goldberg, the number 6 and y
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
|
Sometimes GCC generate code at end of function:
cmovge %eax,%edi
mov%edi,%eax
retq
but faster:
cmovl %edi,%eax
retq
Example:
# cat test.c
#define MX 0
#define LIM 7
char char_char(char m)
{if(m>LIM) return(MX); return(m);}
char char_int(int m)
{if(m>LIM) return(MX); return(m)
--- Comment #10 from jonathan dot d dot wetherbee at saic dot com
2009-05-08 15:51 ---
When I run the fortran code: print *, precision(1.e0), digits(1.e0)
I get: 6,24
*.original file yields:
myfunc (real(kind=4) & a, real(kind=4) & b, real(kind=4) & c, real(kind=4) & d,
real(kind=4)
--- Comment #9 from dominiq at lps dot ens dot fr 2009-05-08 15:49 ---
Couldn't it be an alignement problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
--- Comment #8 from kargl at gcc dot gnu dot org 2009-05-08 15:42 ---
(In reply to comment #0)
> Subroutine myfunc(a,b,c,d,e,res1,res2)
> Real a,b,c,d,e
> Parameter (g = 273.15)
> res1 = a*(b/a)**((c-d-g)/(e-d))
> res2 = (b/a)**((c-d-g)/(e-d))
> res2
--- Comment #7 from jonathan dot d dot wetherbee at saic dot com
2009-05-08 15:40 ---
Checked the size of a float with sizeof(float) and got 4 bytes. How can I
check the size of REAL in fortran?
When I try the USE ISO_C_BINDING I get the same result.
--
http://gcc.gnu.org/bugzill
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-08 15:36 ---
Adding the print *, ... in the subroutines and mixing C and Fortran, I get:
310.40363 0.000
Function 1:
result 1: 310.403625
result 2: 310.403625
23223.025 0.000
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-05-08 15:30 ---
You use 'float' in the C routines and 'REAL' in the fortran code. What their
respective size? Is float always 4 byte in C? I think default-real-kind on
win64 could be 8, not 4? Could also explain why it worked for Do
--- Comment #4 from jonathan dot d dot wetherbee at saic dot com
2009-05-08 15:27 ---
When I run Dominique's main function written in fortran, I get:
res1res2 res1-res2
6.09E-24 310.40363 -310.40363
8.92E-23 23223.025 -23223.025
-4.01E-06 142007.59 -142007.59
--- Comment #3 from kargl at gcc dot gnu dot org 2009-05-08 15:07 ---
Fortran bug reports never have a Severity of Blocker unless
a GCC Release Manager sets that value. Reset to normal.
You forgot to include the actual output you got from
running your code.
You forgot to include the o
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-05-08 15:06
---
> I think this affects 32-bit sparc as well, unless the br* instructions are new
> in sparcv9 (they don't seem to be).
Yes, they are new in V9 and operate only on the full 64-bit register.
--
http://gcc.gnu.
--- Comment #2 from jonathan dot d dot wetherbee at saic dot com
2009-05-08 15:03 ---
I used C code to call the function because the fortran code is being compiled
into a C based application.
When I run the sample main function, the values are obviously different.
Function 1:
result 1
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-08 14:55 ---
Why are you using a code in C for the tests? If I use the following as the main
program
real res1, res2
call myfunc(1000.0,850.0,143.204,30.5280,8.2351,res1,res2)
print *, res1, res1-res2
cal
As shown in:
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg00618.html
=== gnat tests ===
Running target unix/-mabi=32
=== gnat Summary for unix/-mabi=32 ===
# of expected passes635
# of expected failures 6
Running target unix/-mabi=n32
Some equations using exponents on Windows XP Professional 64-bit evaluate
incorrectly, but can be computed correctly by splitting up the equation into
multiple statements.
I apologize in advance if this turns out to be just a MinGW bug, but thought
I'd start with gcc first.
I am using MinGW GFort
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-08 14:14 ---
Subject: Bug 40062
Author: rguenth
Date: Fri May 8 14:14:25 2009
New Revision: 147288
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147288
Log:
2009-05-08 Richard Guenther
PR tree-optimization/
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-08 14:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #17 from dominiq at lps dot ens dot fr 2009-05-08 14:09 ---
Thanks to the second program in
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c6621b97f448b516#
I think I have found a false positive for -fwhole-file (unpatched):
Implicit None
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-08 12:39 ---
Fixed on trunk and for 4.4.1 sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-08 12:28 ---
Subject: Bug 40062
Author: rguenth
Date: Fri May 8 12:28:01 2009
New Revision: 147284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147284
Log:
2009-05-08 Richard Guenther
PR tree-optimization/
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-08 12:24 ---
Subject: Bug 40062
Author: rguenth
Date: Fri May 8 12:24:22 2009
New Revision: 147283
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147283
Log:
2009-05-08 Richard Guenther
PR tree-optimization/
--- Comment #107 from bonzini at gnu dot org 2009-05-08 12:22 ---
Subject: Bug 26854
Author: bonzini
Date: Fri May 8 12:22:30 2009
New Revision: 147282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147282
Log:
2009-05-08 Paolo Bonzini
PR rtl-optimization/33928
--- Comment #83 from bonzini at gnu dot org 2009-05-08 12:22 ---
Subject: Bug 33928
Author: bonzini
Date: Fri May 8 12:22:30 2009
New Revision: 147282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147282
Log:
2009-05-08 Paolo Bonzini
PR rtl-optimization/33928
I noticed that AUTO_INC_DEC is defined a bit oddly in gcc/rtl.h. More
specifically, the condition does not include HAVE_POST_MODIFY_DISP but it does
include HAVE_PRE_MODIFY_DISP twice. Most likely one of these
HAVE_PRE_MODIFY_DISP should be a HAVE_POST_MODIFY_DISP.
The following is the code snippe
--- Comment #4 from sebpop at gmail dot com 2009-05-08 12:12 ---
Subject: Re: [4.3/4.4/4.5 Regression] high
memory usage and compile time in SCEV cprop with -O3
> + Â Â Â /* Increase the limit by the PHI argument number to avoid
> exponential
> + Â Â Â Â time and memory
> + /* Increase the limit by the PHI argument number to avoid exponential
> + time and memory complexity. */
This looks good.
Thanks,
Sebastian
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-05-08
11:55 ---
To reproduce the bug, compile the attached testcase
g++-4 -fpreprocessed -S vti.ii
and view the very end of the .s file emitted:
.section .drectve
.ascii " -export:_ZTV12XMLException,da
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-08
11:53 ---
Created an attachment (id=17826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826&action=view)
Simple testcase
It doesn't get much more trivial than this.
--
http://gcc.gnu.org/bugzilla/sho
Precisely as subject. All other class members and related data (e.g. vtables,
synthetic ctors) will be tagged dllexport if the class itself is dllexport, and
-export comments will be added listing their symbols in the .drectve section.
Typeinfo data alone will not receive the dllexport attribute,
--- Comment #9 from paolo dot carlini at oracle dot com 2009-05-08 11:38
---
Really, this can be closed, all the recent branches are fine. I also double
checked that another couple of implementations give the same result.
--
paolo dot carlini at oracle dot com changed:
W
--- Comment #3 from scovich at gmail dot com 2009-05-08 11:30 ---
> What|Removed |Added
>
> GCC target triplet|sparc-sun-solaris2.10 |sparc64-sun-solaris2.10
I think this
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-08 11:25 ---
> > As a matter of curiosity, do other compilers catch this?
> Intel does not.
Sure? If I look at the assembler of ifort 11.1 with -O3, I only see:
call __intel_new_proc_init #1.9
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-05-08 10:34 ---
Mixed real/complex arithmetic now handles signed zeros properly and GCC
will no longer try to second-guess complex/complex arithmetic as having
one half real or imaginary just because the imaginary or real part of
that
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-05-08 10:22 ---
Subject: Bug 24581
Author: jsm28
Date: Fri May 8 10:22:08 2009
New Revision: 147281
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147281
Log:
PR c/24581
* c-typeck.c (build_binary_op): Handle
--- Comment #3 from joseph at codesourcery dot com 2009-05-08 10:19 ---
Subject: Re: spurious format string warnings
On Fri, 8 May 2009, pinskia at gcc dot gnu dot org wrote:
> is happening here, it is assuming %qE does not take an argument). I don't see
> an issue really except you
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-05-08 10:17
---
brz is not used because *ptr is an int, it would be used with a long.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-08 09:52 ---
Or rather
Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 147237)
+++ tree-scalar-evolution.c (working copy)
@@ -1320,
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-08 09:47 ---
The issue is that with follow_ssa_edge_in_condition_phi we end up with
exponential time and space complexity because we have several PHI nodes
in our chain that have a large number of PHI arguments.
The following fi
--- Comment #82 from bonzini at gnu dot org 2009-05-08 09:41 ---
Hm, looking at the time reports the patch will save about 30-40% of the fwprop
execution time, and should fix the memory hog problem, but will still leave in
the 70s needed to compute reaching definitions. I guess it's a s
--- Comment #1 from scovich at gmail dot com 2009-05-08 09:38 ---
Sorry, the C code should have been:
long spin(int volatile* ptr) {
long rval=0;
while(*ptr) rval++;
return rval;
}
--
scovich at gmail dot com changed:
What|Removed |Add
Compiling the following function with -O3 gives the following assembly output:
void spin(int volatile* ptr) {
while(*ptr);
return;
}
spin:
.LLFB1:
.register %g2, #scratch
lduw[%o0], %g1 ! 8 *zero_extendsidi2_insn_sp64/2 [length
= 1]
cmp %g1
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-05-08 09:30
---
(In reply to comment #3)
> As a matter of curiosity, do other compilers catch this?
Intel does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-08 09:11 ---
Fixed with r147279. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-08 09:08 ---
Subject: Bug 39876
Author: janus
Date: Fri May 8 09:08:13 2009
New Revision: 147279
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147279
Log:
2009-05-08 Janus Weil
PR fortran/39876
* intr
This might relate to bug 34158 comment #6.
When throwing an exception in the constructor of an object being allocated as a
result of a call to a (placement) new expression, the corresponding (placement)
operator delete does not get called - unless the new expression is placed
inside a try-catch bl
--- Comment #3 from bradh at frogmouth dot net 2009-05-08 07:58 ---
Looks like the install is now dealing with this.
--
bradh at frogmouth dot net changed:
What|Removed |Added
--- Comment #81 from bonzini at gnu dot org 2009-05-08 07:55 ---
Created an attachment (id=17825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17825&action=view)
speed up fwprop and enable it at -O1
Here is a patch I'm bootstrapping to remove fwprop's usage of UD chains. It
does
--- Comment #80 from bonzini at gnu dot org 2009-05-08 07:51 ---
Subject: Bug 33928
Author: bonzini
Date: Fri May 8 07:51:46 2009
New Revision: 147274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147274
Log:
2009-05-08 Paolo Bonzini
PR rtl-optimization/33928
--- Comment #79 from bonzini at gnu dot org 2009-05-08 07:18 ---
I'm cobbling up the DIY dataflow patch and it is all but ugly, actually.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
95 matches
Mail list logo
