Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40004 was a bug report that I
filed on the missing plugin headers.
That is now resolved - the headers are installed. I've closed the bug report.
However I'm not sure how my application / buildsystem is meant to find the
headers. Is there a way
It seems that when set in a loop, the program is able to perform some
type of optimization to actually get the use of the offsets where as
in the case of no loop, we have twice the calculations of instructions
for each address calculations.
I suggest you look at the dumps for i386 to see
Dave Korn wrote:
Andrew Haley wrote:
eCos@ wrote:
===
int *p;
int main(void)
{
p++;
__asm__ __volatile__ (::);
p++;
}
===
assembly code is like:
'addl $4, %eax'
'addl
2009/5/8 Brad Hards br...@frogmouth.net:
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40004 was a bug report that I
filed on the missing plugin headers.
That is now resolved - the headers are installed. I've closed the bug report.
However I'm not sure how my application / buildsystem is
Andrew Haley wrote:
Dave Korn wrote:
So, this is a real bug then - but it's a missed optimisation in the first
case, not a bogus one in the second case?
Probably, but it's not a very interesting one. For what it's worth, the
tree dumps are identical right up to the very last tree
Rafael Espindola wrote:
2009/5/8 Brad Hards br...@frogmouth.net:
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40004 was a bug report that I
filed on the missing plugin headers.
That is now resolved - the headers are installed. I've closed the bug report.
However I'm not sure how my
Dave Korn wrote:
Andrew Haley wrote:
Dave Korn wrote:
So, this is a real bug then - but it's a missed optimisation in the first
case, not a bogus one in the second case?
Probably, but it's not a very interesting one. For what it's worth, the
tree dumps are identical right up to the very
Consider a class hierarchy with single inheritance, as follows:
struct A {
virtual ~A() = default;
}
struct B : public A {
virtual ~B() = default;
};
and
A* p = new B();
then how can I get the type_info object of the base class of B?
Or, in other words, how do I enumerate the
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Samuel Tardieu
Sent: 06 May 2009 11:06
To: gcc@gcc.gnu.org
Subject: Multilib for ARM in thumb2 mode
Right now, to be able to compile a mutilib-enabled ARM-targeted
compiler
supporting
* Alexandre Pereira Nunes alexandre.nu...@gmail.com [2009-05-08 11:24:14
-0300]
| Don't you already get this if you created a toolchain with
| --with-arch=armv7-m and the multilib for thumb ? A toolchain configured for
| --with-arch=armv7-m and the multilib for thumb would automatically cover
Piotr Wyderski wrote:
Namely, where do you keep the direct base information about
a class type and what data structures from libstdc++ should I
become familiar with? And the last question: is the format
expected to stable in terms of GCC development?
libstdc++-v3/libsupc++/typeinfo.
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Paolo Bonzini
Sent: 07 May 2009 14:53
To: m...@codesourcery.com
Cc: gcc@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw
Subject: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report
Dave Korn wrote:
To find the base classes, look at the typeinfo for the class, which will be
abi::__class_type_info or one of its derivatives as specified in the ABI doc
It should be __si_class_type_info in my case.
Beautiful! Many thanks Dave :-)
BTW, how do you know what derivate is
The current snapshot 4.5-20090507 fails to bootstrap on Cygwin:
[...]
/tmp/build/./prev-gcc/xgcc -B/tmp/build/./prev-gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
On Wed, May 06, 2009 at 02:29:46AM -0400, DJ Delorie wrote:
Andrew Pinski pins...@gmail.com writes:
You could do what the rs6000 back-end does for the altivec builtins
and resolve them while the parser is run (the SPU back-end does the
same thing too). Yes there are opaque vector types,
Oliver == Oliver Kellogg oliver.kell...@t-online.de writes:
Oliver Also, I'm thinking that in multi-source mode, the switch -o
Oliver can perhaps continue to be used - not by giving a filename
Oliver but instead by giving a directory. All object files would then
Oliver be placed in the given
Ian suggestion worked perfectly, thanks. Can you tell me the macro/function
name to look up
to work out the secondary reload you're mentioning?
- Original Message
From: Michael Meissner meiss...@linux.vnet.ibm.com
To: Ian Lance Taylor i...@google.com
Cc: Iceman iceman_...@yahoo.com;
Angelo Graziosi angelo.grazi...@alice.it writes:
The current snapshot 4.5-20090507 fails to bootstrap on Cygwin:
There is a patch here:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html
Not sure if it has been approved. I sort of thing that
(enum format_lengths) 0
should be
Ian Lance Taylor wrote:
Angelo Graziosi angelo.grazi...@alice.it writes:
The current snapshot 4.5-20090507 fails to bootstrap on Cygwin:
It did bootstrap effortlessly for me, once I logged off to clear hung
processes, with the usual disabling of strict warnings. I'll let
On Friday 08 May 2009 10:37:27 pm Dave Korn wrote:
Instead of pkg-config, the tradition for GCC is to use one of the
driver's default switches. Does
gcc -print-file-name=plugin/include/whatever.h
work for you?
$ /opt/gccsvn/bin/gcc -print-file-name=plugin/include/gcc-plugin.h
Perfect, thank you!
- Original Message
From: Michael Meissner meiss...@linux.vnet.ibm.com
To: Iceman iceman_...@yahoo.com
Cc: Michael Meissner meiss...@linux.vnet.ibm.com; Ian Lance Taylor
i...@google.com; g...@gnu.org
Sent: Friday, May 8, 2009 3:45:20 PM
Subject: Re: Avoiding
Hi!
I'm porting GCC to a software VM with 32 32bit registers, and 32 64bit
registers.
The 64bit registers are used for DI, SF and DF mode. Pointers and QI, HI and SI
modes are handled with 32bit registers.
The first 8 32bit parameters of functions are passed into the first 8 32bit
registers
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-05-08 06:27 ---
Subject: Bug 37577
Author: tkoenig
Date: Fri May 8 06:27:37 2009
New Revision: 147269
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147269
Log:
2009-05-08 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- Comment #78 from bonzini at gnu dot org 2009-05-08 06:51 ---
Subject: Bug 33928
Author: bonzini
Date: Fri May 8 06:51:12 2009
New Revision: 147270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147270
Log:
2009-05-08 Paolo Bonzini bonz...@gnu.org
PR
--- 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
--- 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=gccview=revrev=147274
Log:
2009-05-08 Paolo Bonzini bonz...@gnu.org
PR
--- 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=17825action=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
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
--- 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 #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=gccview=revrev=147279
Log:
2009-05-08 Janus Weil ja...@gcc.gnu.org
PR
--- 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 #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
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
--- 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
--- 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
--- 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
--- 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)
@@
--
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 #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
--- 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 #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=gccview=revrev=147281
Log:
PR c/24581
* c-typeck.c (build_binary_op): Handle
--- 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
--- 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 #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 #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:
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
--- 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=17826action=view)
Simple testcase
It doesn't get much more trivial than this.
--
--- 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
+ /* Increase the limit by the PHI argument number to avoid exponential
+ time and memory complexity. */
This looks good.
Thanks,
Sebastian
--- 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
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
--- 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=gccview=revrev=147282
Log:
2009-05-08 Paolo Bonzini bonz...@gnu.org
PR
--- 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=gccview=revrev=147282
Log:
2009-05-08 Paolo Bonzini bonz...@gnu.org
PR
--- 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=gccview=revrev=147283
Log:
2009-05-08 Richard Guenther rguent...@suse.de
PR
--- 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=gccview=revrev=147284
Log:
2009-05-08 Richard Guenther rguent...@suse.de
PR
--- 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 #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 #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 #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=gccview=revrev=147288
Log:
2009-05-08 Richard Guenther rguent...@suse.de
PR
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
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
--- 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
--- 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
--- 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.
--
--- 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
--- 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 #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
--- 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 #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.
--
--- 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 #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 #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) e,
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(mLIM) return(MX); return(m);}
char char_int(int m)
{if(mLIM) return(MX);
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
|
--- 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
--- 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 #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
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
--- 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=17828action=view)
Replacement test case that doesn't need -DTYPE to show the bug
Replacement test case.
--
--- 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=17829action=view)
Powerpc example code
This code was compiled with -O3 -maltivec.
--
--- 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=17830action=view)
X86_64 example code
This code was compiled with an x86_64 compiler with the -O3 -msse3 options.
--- 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=17831action=view)
Vectorizer verbose output
This is the output from the Powerpc compiler with -fdump-tree-vect
--- 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=17827action=view)
test case
This code is an example of the code that generates sub-optimal code.
--
--- 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
--- 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 #8 from danglin at gcc dot gnu dot org 2009-05-08 18:21 ---
Introduced in revision 146894:
2009-04-28 Andrew Pinski pins...@gmail.com
PR target/39929
* config/darwin.c (machopic_gen_offset): Check
currently_expanding_to_rtl if current_ir_type
--- 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=gccview=revrev=147293
Log:
gcc/
2009-05-08 H.J. Lu hongjiu...@intel.com
Andrew
--- 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
--- 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
--- 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 #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
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
--- 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=17832action=view)
Preprocessed source of source that triggers ICE
--
/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 #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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
GCC target triplet|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- 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
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-05-08 20:52
---
Debugging cc1plus for this slightly reduced program:
templatetypename T
struct x
{
protected:
typedef int type;
};
templatetypename T
struct y : public xT
{
typename xT::type z;
};
template
struct
--- 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|
1 - 100 of 118 matches
Mail list logo
