Re: gcc visibility used by moz

2006-07-13 Thread Jason Merrill
Gabriel Dos Reis wrote: Joe Buck wrote: Now, this being a conscious decision for ODR violation, it would probably need to be documented because then we may have typeinfo1 != typeinfo2 and yet !typeinfo1.before(typeinfo2) !typeinfo2.before(typeinfo1) There are probably other

BIT_FIELD_REF on the LHS

2006-07-13 Thread Andrew Pinski
So I started to try to fold *(type*)(vector_type_var) into BIT_FIELD_REF t, 32, 0 but I ran into a bug where the SSA messes itself up. This works for the right hand side just fine as BIT_FIELD_REFSSA_NAME, x, y is easyly valid gimple. When the BIT_FIELD_REF is on the left hand side, it turns

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Richard Guenther
On 7/13/06, Andrew Pinski [EMAIL PROTECTED] wrote: So I started to try to fold *(type*)(vector_type_var) into BIT_FIELD_REF t, 32, 0 but I ran into a bug where the SSA messes itself up. This works for the right hand side just fine as BIT_FIELD_REFSSA_NAME, x, y is easyly valid gimple. When the

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Steven Bosscher
On 7/13/06, Richard Guenther [EMAIL PROTECTED] wrote: On 7/13/06, Andrew Pinski [EMAIL PROTECTED] wrote: So I started to try to fold *(type*)(vector_type_var) into BIT_FIELD_REF t, 32, 0 but I ran into a bug where the SSA messes itself up. This works for the right hand side just fine as

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Paolo Bonzini
PS http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02150.html added the ability for having BIT_FIELD_REF on the LHS. Yes, but IIRC that was only for addressable things, not for registers. As Steven said, handling it would be a mess like it was for RTL SSA. So, you Do Not Want this for

Re: request for new a syntactic design for C/C++.

2006-07-13 Thread Vladimir 'Yu' Stepanov
Ian Lance Taylor wrote: Vladimir 'Yu' Stepanov [EMAIL PROTECTED] writes: Current syntax C/C++: load_ptr = typeof(load_ptr)(((char *)init_ptr) - \ offsetof(typeof(init_ptr), field); The offered syntax: load_ptr-field = init_ptr; Interesting idea, but C/C++

Re: gcc visibility used by moz

2006-07-13 Thread Gabriel Dos Reis
Jason Merrill [EMAIL PROTECTED] writes: | Gabriel Dos Reis wrote: | Joe Buck wrote: | Now, this being a conscious decision for ODR violation, it would | probably need to be documented because then we may have | typeinfo1 != typeinfo2 | and yet | !typeinfo1.before(typeinfo2)

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Diego Novillo
Andrew Pinski wrote on 07/13/06 03:27: I don't see anything in either tree.def or tree-ssa.texi which would cause the orginal non-gimplified tree to be invalid. So my question is should we document that BIT_FIELD_REF on the lhs for a SSA_NAME invalid gimple? SSA_NAMEs should not be valid

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Andrew Pinski
On Jul 13, 2006, at 9:32 PM, Diego Novillo wrote: Got a test case where we produce BIT_FIELD_REF SSA_NAME,... in either side of the assignment? Well a simple one like for the RHS on PPC-linux-gnu with -maltivec (and -O1): #define vector __attribute__((vector_size(16) )) vector float

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Diego Novillo
Andrew Pinski wrote on 07/13/06 08:37: #define vector __attribute__((vector_size(16) )) vector float f(vector float t, vector t1) { return t/t1; } -- Pinski That definitely seems wrong. We shouldn't be considering vector types to be GIMPLE register types if we are going to be

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Andrew Pinski
On Jul 13, 2006, at 10:06 PM, Diego Novillo wrote: That definitely seems wrong. We shouldn't be considering vector types to be GIMPLE register types if we are going to be chunking them out with BIT_FIELD_REF. The verifier ought to check that. I am thinking about cleaning this up by

Bug in the specs or bug in the code?

2006-07-13 Thread jacob navia
Hi Bug in the specs or bug in the code? I do not know, but one of this is wrong: In the Linux Standard specs in http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html it is written in the specification of the FDE (Frame Description Entry) the following:

How to insert dynamic code? (continued)

2006-07-13 Thread jacob navia
Hi Context: I am writing a JIT and need to register the frame information about the generated program within the context of a larger C++ program compiled with g++. Stack layout is like this: catch established by C++ JITTED code generated dynamically JITTED code

Re: Bug in the specs or bug in the code?

2006-07-13 Thread Daniel Jacobowitz
On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote: In the Linux Standard specs in http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html it is written in the specification of the FDE (Frame Description Entry) the following: I suggest you

Re: How to insert dynamic code? (continued)

2006-07-13 Thread Andrew Haley
jacob navia writes: Hi Context: I am writing a JIT and need to register the frame information about the generated program within the context of a larger C++ program compiled with g++. Stack layout is like this: catch established by C++ JITTED code generated

Re: How to insert dynamic code? (continued)

2006-07-13 Thread jacob navia
Andrew Haley wrote: The way you do not reply to mails replying to your questions doesn't encourage people to help you. Please try harder to answer. I did answer last time but directly to the poster that replied, and forgot to CC the list. Excuse me for that. I suspect that the gcc

Re: Different invariants about the contents of static links

2006-07-13 Thread DebianTux23
http://earth.google.com/download-earth.html On 7/13/06, DebianTux23 [EMAIL PROTECTED] wrote: http://earth.google.com/download-earth.html On 07 Jul 2006 10:11:01 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote: Rodney M. Bates [EMAIL PROTECTED] writes: The following example C code and

Re: Bug in the specs or bug in the code?

2006-07-13 Thread jacob navia
Daniel Jacobowitz wrote: On Thu, Jul 13, 2006 at 04:46:19PM +0200, jacob navia wrote: In the Linux Standard specs in http://www.freestandards.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/ehframechpt.html it is written in the specification of the FDE (Frame Description Entry) the

Re: How to insert dynamic code? (continued)

2006-07-13 Thread Daniel Jacobowitz
On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote: So, what happens when _Unwind_Find_registered_FDE is called? Does it find the EH data you have registered? Yes but then it stops there instead of going upwards and finding the catch! It is as my insertion left the list of

Re: Bug in the specs or bug in the code?

2006-07-13 Thread Daniel Jacobowitz
On Thu, Jul 13, 2006 at 05:10:19PM +0200, jacob navia wrote: Mmmm report this problem to the LSB. Maybe you have someone there I could reach? An email address? There is no feedback or bugs button in their page. Try http://www.freestandards.org/en/LSB - lsb-discuss mailing list? --

Re: Wiki down for a few days

2006-07-13 Thread Daniel Berlin
Manuel López-Ibáñez wrote: Hi Daniel, The Wcoercion porject page is currently up at http://gcc.gnu.org/wiki/Wcoercion and it is vandalised. Yet, I cannot revert or change it. Could you do something about this please? Taking it down for a few days would be better than current situation.

Re: request for new a syntactic design for C/C++.

2006-07-13 Thread Vladimir 'Yu' Stepanov
Mike Stump wrote: On Jul 9, 2006, at 10:52 PM, Vladimir 'Yu' Stepanov wrote: I would like to offer one expansion for C/C++. Did you just reinvent downcasting in C++? If so, C++ already has that feature!? As for C, C, I'd claim C already has that feature[1], you merely have to put in a

Re: How to insert dynamic code? (continued)

2006-07-13 Thread jacob navia
Daniel Jacobowitz wrote: On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote: So, what happens when _Unwind_Find_registered_FDE is called? Does it find the EH data you have registered? Yes but then it stops there instead of going upwards and finding the catch! It is as

Re: How to insert dynamic code? (continued)

2006-07-13 Thread Andrew Haley
jacob navia writes: Andrew Haley wrote: I suspect that the gcc unwinder is relying on __dl_iterate_phdr to scan the loaded libraries and isn't using the region that you have registered. But this is odd, becasue when I look at _Unwind_Find_FDE in unwind-dw2-fde-glibc.c, I see:

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Paolo Bonzini
Diego Novillo wrote: Andrew Pinski wrote on 07/13/06 08:37: #define vector __attribute__((vector_size(16) )) vector float f(vector float t, vector t1) { return t/t1; } -- Pinski That definitely seems wrong. We shouldn't be considering vector types to be GIMPLE register types if we are

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Diego Novillo
Paolo Bonzini wrote on 07/13/06 11:55: But if you say this is dangerous, yes, I agree that the best thing to do is to treat VECTOR_TYPEs like COMPLEX_TYPEs and use DECL_COMPLEX_GIMPLE_REG_P. Does COMPOSITE_TYPE_P, and DECL_COMPOSITE_GIMPLE_REG_P sound good as names? Yes, I think that

gcc 4.x can not optimize access for array well

2006-07-13 Thread Atsushi Nemoto
I found gcc 4.1.1 (and 4.2) can not optimize this simple code well. void foo(int *a) { int i; for (i = 0; i 100; i++) a[0] += a[1]; } If I compile this code with -O2, instructions to load from a[1] and store to a[0] are both inside a loop. Is this a know issue?

Re: gcc visibility used by moz

2006-07-13 Thread Joe Buck
I wrote [for two classes S with visibility == hidden ] | | We can have two distinct | | classes named S, and no one can tell. Each bit of code will see one | | definition of S. Jason Merrill [EMAIL PROTECTED] writes: | I think that Joe's point is that IF you have two classes named S,

Re: A correction: Different invariants about the contents of static links]

2006-07-13 Thread Ian Lance Taylor
Rodney M. Bates [EMAIL PROTECTED] writes: When executing in foo, the frame pointer will point to a fixed spot in the activation record of foo. On i386, the FP is %ebx and it points to the dynamic link field. From there, loc is at displacement -4. Code in the body of foo will reference x at

x86_64 ABI

2006-07-13 Thread Maurizio Vitale
my understanding of the x86_64 ABI is that the following structure should be passed in registers: struct data { unsigned int x; unsigned int y; unsigned long z; }; but when I compile: #include stdio.h struct data { unsigned int x : 32; unsigned int y

Re: How to insert dynamic code? (continued)

2006-07-13 Thread Mike Stump
On Jul 13, 2006, at 8:48 AM, jacob navia wrote: 1) I generate exactly the same code now as gcc: You don't want to generate exactly the same code as gcc, unless it is exactly the same case; you want to generate the correct code. Divide and concur. Do simple things work? For example, do:

Re: How to insert dynamic code? (continued)

2006-07-13 Thread Seongbae Park
On 7/13/06, jacob navia [EMAIL PROTECTED] wrote: Daniel Jacobowitz wrote: On Thu, Jul 13, 2006 at 05:06:25PM +0200, jacob navia wrote: So, what happens when _Unwind_Find_registered_FDE is called? Does it find the EH data you have registered? Yes but then it stops there instead of going

Re: How to insert dynamic code? (continued)

2006-07-13 Thread Daniel Jacobowitz
On Thu, Jul 13, 2006 at 11:21:04AM -0700, Seongbae Park wrote: The above code looks incorrect, for various reasons, not the least of which is that you're assuming CIE/FDE are fixed-length. There are various factors that affect FDE/CIE depending on PIC/non-PIC, C or C++, 32bit/64bit, etc -

Re: How to insert dynamic code? (continued)

2006-07-13 Thread jacob navia
Seongbae Park wrote: The above code looks incorrect, for various reasons, not the least of which is that you're assuming CIE/FDE are fixed-length. This is a trivial thing I will add later. There are various factors that affect FDE/CIE depending on PIC/non-PIC, C or C++, 32bit/64bit, etc -

gcc-4.0-20060713 is now available

2006-07-13 Thread gccadmin
Snapshot gcc-4.0-20060713 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060713/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

campionati mondiale per stragi - la classifica

2006-07-13 Thread elcicala
caro lettore Dopo l'esito dei vincitori dei mondiali di calcio germania 2006 volete sapere chi sono i campioni mondiali per stragi? se ti interessa visita il sito: http://www.elcicala.com il tuo indirizzo e stato preso da elenchi pubblici e

[PATCH] Install drivers from gcc/Makefile.in

2006-07-13 Thread Rafael Espíndola
The attached patch moves the basic installation of the compiler drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in has only to inform the driver's name. Additional setup like setting the c++ - g++ links remains in the Make-lang.in Ok for trunk when stage1 starts? :ADDPATCH

Re: [PATCH] Install drivers from gcc/Makefile.in

2006-07-13 Thread Andrew Pinski
On Jul 14, 2006, at 9:41 AM, Rafael Espíndola wrote: The attached patch moves the basic installation of the compiler drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in has only to inform the driver's name. Additional setup like setting the c++ - g++ links remains in the

Re: [PATCH] Install drivers from gcc/Makefile.in

2006-07-13 Thread Daniel Jacobowitz
On Thu, Jul 13, 2006 at 09:41:45PM -0300, Rafael Espíndola wrote: The attached patch moves the basic installation of the compiler drivers from gcc/*/Make-lang.in to gcc/Makefile.in. The Make-lang.in has only to inform the driver's name. Additional setup like setting the c++ - g++ links

expand_divmod algorithm patented?

2006-07-13 Thread Joern Rennecke
PJ has posted a news pick on Groklaw about a new patent which, afar as I can tell, claims the algorithm that Tege has contributed to expmed.c:expand_divmod in 1994 (r7598) http://www.freshpatents.com/Method-and-apparatus-for-efficient-software-based-integer-division-dt20060504ptan20060095494.php

Re: BIT_FIELD_REF on the LHS

2006-07-13 Thread Andrew Pinski
On 7/13/06, Paolo Bonzini [EMAIL PROTECTED] wrote: Yes, but IIRC that was only for addressable things, not for registers. Changing DECL_COMPLEX_GIMPLE_REG_P to DECL_GIMPLE_REG_P and adding support for it for vector types has fixed this problem. In fact now I can get vec_extract and vec_set

[Bug c/28368] New:

2006-07-13 Thread gcc-bugzilla at gcc dot gnu dot org
-std=c89 doesn't warn about gcc's ?: extension Environment: System: Linux rho 2.6.15-1-amd64-k8 #2 Tue Mar 7 06:53:26 UTC 2006 x86_64 GNU/Linux Architecture: x86_64 host: x86_64-unknown-linux-gnu build: x86_64-unknown-linux-gnu target: x86_64-unknown-linux-gnu configured with:

[Bug fortran/28213] ICE: Hollerith constant

2006-07-13 Thread fengwang at gcc dot gnu dot org
--- Comment #6 from fengwang at gcc dot gnu dot org 2006-07-13 06:34 --- Fixed on trunk and 4.1 -- fengwang at gcc dot gnu dot org changed: What|Removed |Added

[Bug fastjar/28359] fastjar directory traversal problem

2006-07-13 Thread rguenth at gcc dot gnu dot org
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-07-13 07:39 --- Reopening then... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug fastjar/28359] fastjar directory traversal problem

2006-07-13 Thread rguenth at gcc dot gnu dot org
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-07-13 07:40 --- ...to assign myself. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz
--- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-07-13 07:58 --- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific) I-cache. this only matters if this increase in code size will make the code go out

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz
--- Comment #19 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-07-13 08:01 --- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific) I-cache. this only matters if this increase in code size will make the code go out

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread zackw at panix dot com
--- Comment #20 from zackw at panix dot com 2006-07-13 08:25 --- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific) However, ch isn't just copying the loop header; it is also copying the *entire body of the loop*, which nothing can

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread zackw at panix dot com
--- Comment #21 from zackw at panix dot com 2006-07-13 08:28 --- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific) on your real program, how much performance do you gain by hand-rewriting the assembler to look the way you like?

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread rguenth at gcc dot gnu dot org
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-07-13 08:28 --- For practical purposes (determining the loop runs at least once) it needs to duplicate the exit condition. Which happens to be difficult here, as there are multiple loop exits. --

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz
--- Comment #23 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-07-13 09:00 --- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific) on your real program, how much performance do you gain by hand-rewriting the

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

2006-07-13 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz
--- Comment #24 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-07-13 09:03 --- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific) However, ch isn't just copying the loop header; it is also copying the *entire body

[Bug c++/28370] New: undefined reference (to a complicated template construct) at link time

2006-07-13 Thread caolanm at redhat dot com
../unxlngi6.pro/slo/uuid.o: In function `create': ../../inc/rtl/instance.hxx:292: undefined reference to `(anonymous namespace)::rtl_Instance(anonymous namespace)::Pool, rtl::Static(anonymous namespace)::Pool, (anonymous namespace)::PoolHolder::StaticInstance, osl::Guardosl::Mutex,

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread caolanm at redhat dot com
--- Comment #1 from caolanm at redhat dot com 2006-07-13 09:42 --- Created an attachment (id=11877) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11877action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread caolanm at redhat dot com
--- Comment #2 from caolanm at redhat dot com 2006-07-13 09:43 --- Created an attachment (id=11878) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11878action=view) original -6 nm output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread caolanm at redhat dot com
--- Comment #3 from caolanm at redhat dot com 2006-07-13 09:43 --- Created an attachment (id=11879) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11879action=view) new nm -7 output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370

[Bug c++/28361] Pointer arithmetic failure

2006-07-13 Thread pfister at reith-pfister dot de
--- Comment #2 from pfister at reith-pfister dot de 2006-07-13 10:08 --- Subject: Re: Pointer arithmetic failure Hello, thanks for your immediate response, but i can't repeat the bug today. Yesterday, i spent one day in evaluating the bug in my application and now it seems to be

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread caolanm at redhat dot com
--- Comment #4 from caolanm at redhat dot com 2006-07-13 11:06 --- Created an attachment (id=11880) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11880action=view) diff against testme.ii which will make it work for me This attachment is a diff against the testme.ii and makes the

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread pinskia at gcc dot gnu dot org
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-13 11:53 --- This is invalid code with no diagnostic required. See the full explaination in PR 28360 which is exactly the same case. In fact with a real testcase :). *** This bug has been marked as a duplicate of 28360 ***

[Bug c++/28360] [4.2 regression] undefined reference when header contains additional namespace

2006-07-13 Thread pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-13 11:53 --- *** Bug 28370 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread pinskia at gcc dot gnu dot org
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-13 11:55 --- Basicially the code was violating ODR rules before because of the anonymous namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370

[Bug c++/28361] Pointer arithmetic failure

2006-07-13 Thread pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-13 12:06 --- So closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28370] undefined reference (to a complicated template construct) at link time

2006-07-13 Thread pinskia at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-13 12:19 --- Note I think you should have first checked FSF 4.1.2 which will have not this issue. 4.2.0 might have it, I might had been wrong at closing as a dup, that might be because I am tried and had a long day and it is

[Bug c++/28114] [4.0/4.1/4.2 regression] ICE with struct definition in argument of template function

2006-07-13 Thread reichelt at gcc dot gnu dot org
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-07-13 13:02 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28051] [4.0 regression] ICE on invalid conversion operator

2006-07-13 Thread reichelt at gcc dot gnu dot org
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-07-13 13:14 --- The bug is not fixed on the 4.0 branch. The ICE only happens in a different position: bug.cc: In instantiation of 'B0': bug.cc:8: instantiated from here bug.cc:5: error: no type named 'X' in 'struct A0'

[Bug c++/28217] [4.0/4.1 regression] ICE in tree_int_cst_sgn

2006-07-13 Thread reichelt at gcc dot gnu dot org
--- Comment #16 from reichelt at gcc dot gnu dot org 2006-07-13 13:21 --- Jason, would you mind adding a testcase? Thanks! -- reichelt at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28370] [4.2 Regression] undefined reference to template class static variable in an anonymous namespace

2006-07-13 Thread pinskia at gcc dot gnu dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-13 14:08 --- Here is a full reduced self contained testcase: namespace { template typename Inst struct rtl_Instance { static int * m_pInstance; }; template typename Inst int * rtl_Instance Inst::m_pInstance = 0; }

[Bug target/28126] gcc moves an expensive instruction outside of a conditional

2006-07-13 Thread anemo at mba dot ocn dot ne dot jp
--- Comment #5 from anemo at mba dot ocn dot ne dot jp 2006-07-13 14:42 --- Created an attachment (id=11881) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11881action=view) do not put rdhwr instruction on delay slot With this patch, gcc 4.2 (with -O1, -O2) and gcc 4.1.1 with -O1

[Bug target/28126] gcc moves an expensive instruction outside of a conditional

2006-07-13 Thread anemo at mba dot ocn dot ne dot jp
--- Comment #6 from anemo at mba dot ocn dot ne dot jp 2006-07-13 14:58 --- (In reply to comment #2) Although I don't know much about the instruction scheduling, I had a similar problem on SH and it was workarounded with emitting blockage insns. The patch below might work for you,

Re: [Bug c++/28363] New: Default template parameter causes compiler segfault

2006-07-13 Thread DebianTux23
http://earth.google.com/download-earth.html On 7/13/06, DebianTux23 [EMAIL PROTECTED] wrote: http://earth.google.com/download-earth.html On 12 Jul 2006 21:18:46 -, eric dot lemings at roguewave dot com [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] tests]$ gcc --version gcc (GCC) 4.1.0

[Bug c++/28363] Default template parameter causes compiler segfault

2006-07-13 Thread wieseltux23 at gmail dot com
--- Comment #1 from wieseltux23 at gmail dot com 2006-07-13 15:08 --- Subject: Re: New: Default template parameter causes compiler segfault http://earth.google.com/download-earth.html On 7/13/06, DebianTux23 [EMAIL PROTECTED] wrote: http://earth.google.com/download-earth.html On

Re: [Bug c++/28363] New: Default template parameter causes compiler segfault

2006-07-13 Thread DebianTux23
http://earth.google.com/download-earth.html https://www.google.com/accounts/ServiceLogin?service=pagescontinue=http%3A%2F%2Fpages.google.com%3A80%2F On 7/13/06, DebianTux23 [EMAIL PROTECTED] wrote: http://earth.google.com/download-earth.html On 12 Jul 2006 21:18:46 -, eric dot lemings at

[Bug c++/28363] Default template parameter causes compiler segfault

2006-07-13 Thread wieseltux23 at gmail dot com
--- Comment #2 from wieseltux23 at gmail dot com 2006-07-13 15:09 --- Subject: Re: New: Default template parameter causes compiler segfault http://earth.google.com/download-earth.html

[Bug tree-optimization/28210] ICE in is_gimple_min_invariant at -O1.

2006-07-13 Thread reichelt at gcc dot gnu dot org
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-13 15:31 --- Reduced testcase that crashes when compiled with g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0 -O: = extern C int verbose; struct A { char const* foo()

[Bug c/28299] [4.0/4.1/4.2 regression] ICE with -Wmissing-prototypes

2006-07-13 Thread reichelt at gcc dot gnu dot org
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-13 15:44 --- Shorter testcase that ICE's without issuing an error message first: == int foo; void foo() {} == The problem appeared with GCC 3.0. -- reichelt at gcc dot gnu dot org

[Bug c++/28371] New: pointer to function type mistaken when template functions are involved

2006-07-13 Thread joaquin at tid dot es
The following snippet: #include iostream void foo(){} templatetypename Tvoid bar(){} templatetypename T void test(const T) { std::couttypeid(T).name()std::endl; } int main() { test(foo); test(barint); } produces this oputput on gcc version 3.2 20020927 (prerelease) under Cygwin: PFvvE

[Bug c++/28371] pointer to function type mistaken when template functions are involved

2006-07-13 Thread rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-13 15:51 --- Fixed (at least) in 3.3.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread edmar at freescale dot com
--- Comment #9 from edmar at freescale dot com 2006-07-13 16:08 --- I tried the patch on comment 7 on gcc main line from yesterday. It did not work for me: foo.c: In function 'foo': foo.c:1: error: unrecognizable insn: (insn 11 10 12 3 (set (subreg:DF (reg:DI 121) 0)

[Bug c++/28370] [4.2 Regression] undefined reference to template class static variable in an anonymous namespace

2006-07-13 Thread jakub at gcc dot gnu dot org
--- Comment #9 from jakub at gcc dot gnu dot org 2006-07-13 16:25 --- The reason why the var is not emitted seems to be that note_vague_linkage_var is not called on it in finish_static_data_member_decl. If I replace if (! processing_template_decl TREE_PUBLIC (decl))

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread dje at watson dot ibm dot com
--- Comment #10 from dje at watson dot ibm dot com 2006-07-13 16:31 --- Subject: Re: [4.1/4.2 Regression] returning constant double edmar at freescale dot com writes: edmar I tried the patch on comment 7 on gcc main line from yesterday. It did not work edmar for me: Tried

[Bug c++/28343] [4.0/4.1/4.2 regression] ICE with invalid asm specifier for struct member

2006-07-13 Thread patchapp at dberlin dot org
--- Comment #1 from patchapp at dberlin dot org 2006-07-13 16:50 --- Subject: Bug number PR c++/28343 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00584.html --

[Bug c++/28370] [4.2 Regression] undefined reference to template class static variable in an anonymous namespace

2006-07-13 Thread jakub at gcc dot gnu dot org
--- Comment #10 from jakub at gcc dot gnu dot org 2006-07-13 16:50 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof

2006-07-13 Thread patchapp at dberlin dot org
--- Comment #1 from patchapp at dberlin dot org 2006-07-13 17:00 --- Subject: Bug number PR c++/28294 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00586.html --

[Bug c++/28051] [4.0 regression] ICE on invalid conversion operator

2006-07-13 Thread lmillward at gcc dot gnu dot org
--- Comment #10 from lmillward at gcc dot gnu dot org 2006-07-13 17:33 --- Weird, I bootstrapped and tested this patch on the 4.0 branch not long before applying. I'll take a look and see if I can see why the new testcase is ICE'ing. -- lmillward at gcc dot gnu dot org changed:

[Bug tree-optimization/28372] New: Segfault with -fipa-pta

2006-07-13 Thread micis at gmx dot de
With the actual snapshot gcc-4.2-20060708 I get a segfault when I use the option -fipa-pta Michael Cieslinski g++ -fipa-pta -S get.ii -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2-20060708/configure --prefix=/usr/local/gcc42s --program-suffix=42s

[Bug tree-optimization/28372] Segfault with -fipa-pta

2006-07-13 Thread micis at gmx dot de
--- Comment #1 from micis at gmx dot de 2006-07-13 17:54 --- Created an attachment (id=11882) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11882action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28372

[Bug bootstrap/27794] stack explosion

2006-07-13 Thread sje at cup dot hp dot com
--- Comment #4 from sje at cup dot hp dot com 2006-07-13 17:57 --- Eric, do you have any new information on this problem? I cannot reproduce it. -- sje at cup dot hp dot com changed: What|Removed |Added

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread edmar at freescale dot com
--- Comment #11 from edmar at freescale dot com 2006-07-13 18:01 --- I tested with both examples. Both fails with the same ICE. I am sure I am using the right compiler, because I invoked it explictitly with: ./install_area/gcc-trunk-20060712-e500v2/bin/powerpc-unknown-linux-gnuspe-gcc

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

2006-07-13 Thread janis at gcc dot gnu dot org
--- Comment #18 from janis at gcc dot gnu dot org 2006-07-13 18:18 --- A regression hunt on powerpc-linux using the C testcase from comment #6 identified the following patch: http://gcc.gnu.org/viewcvs?view=revrev=100793 r100793 | rth | 2005-06-09 07:43:40 + (Thu, 09 Jun

[Bug c++/28365] error: ' error: 'MyClass::MyClass(const MyClass)' is private error: within this context

2006-07-13 Thread sebor at roguewave dot com
--- Comment #2 from sebor at roguewave dot com 2006-07-13 19:07 --- If it is in our (Rogue Wave) current code, could you please let us know where so we can look into fixing it? (It's doesn't matter whther gcc does the right thing here or not, our code should be portable either way.)

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread dje at watson dot ibm dot com
--- Comment #12 from dje at watson dot ibm dot com 2006-07-13 19:58 --- Subject: Re: [4.1/4.2 Regression] returning constant double edmar at freescale dot com writes: edmar And to kill the last shread of doubt, here I am using the xgcc present on the edmar very same build

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread edmar at freescale dot com
--- Comment #13 from edmar at freescale dot com 2006-07-13 20:09 --- What about now: /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/xgcc -B/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v2/gcc/ -O2 -c foo.c foo.c: In function 'f': foo.c:1: error: unrecognizable insn: (insn

[Bug regression/28373] New: C code gives unaligned access

2006-07-13 Thread kminola at eng dot umd dot edu
/* gcc-4.1.1 gives unaligned access on alphaev68-dec-osf5.1b regression from gcc-3.4.4 % gcc -v Using built-in specs. Target: alphaev68-dec-osf5.1b Configured with: /usr/local/gcc-4.1.1/src/gcc-4.1.1/configure --enable-languages=c --prefix=/usr/local/gcc-4.1.1/alpha-OSF1-V5 Thread model:

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread dje at watson dot ibm dot com
foo.c $ ./xgcc -B./ -v Reading specs from ./specs Target: powerpc-unknown-linux-gnuspe Configured with: /farm/dje/src/src/configure --target=powerpc-unknown-linux-gnuspe --enable-e500_double --enable-languages=c Thread model: posix gcc version 4.2.0 20060713 (experimental) $ cat foo.s .file

[Bug target/27287] [4.1/4.2 Regression] returning constant double

2006-07-13 Thread edmar at freescale dot com
--- Comment #15 from edmar at freescale dot com 2006-07-13 20:48 --- Ahhha, I found the problem. My patch is wrong: This line + (match_operand:DF 1 register_operand r,m))] should read + (match_operand:DF 1 input_operand r,m))] I don't know how I made this mess, I will try

[Bug regression/28373] C code gives unaligned access

2006-07-13 Thread falk at debian dot org
--- Comment #1 from falk at debian dot org 2006-07-13 20:58 --- The conversion from int* to aa* is only defined if the pointer is correctly aligned. Even if it was correctly aligned, dereferencing this pointer is undefined behavior (see -Wstrict-aliasing documentation). So this is not

[Bug libfortran/26893] kinds.h not generated, causing failure

2006-07-13 Thread langton at gcc dot gnu dot org
--- Comment #17 from langton at gcc dot gnu dot org 2006-07-13 21:00 --- (In reply to comment #16) Thanks but it doesn't work... Did you re-run 'configure' after rebuilding GMP and MPFR? What happens if you try to configure and bootstrap from a clean object directory? --

[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6

2006-07-13 Thread langton at gcc dot gnu dot org
--- Comment #8 from langton at gcc dot gnu dot org 2006-07-13 21:11 --- (In reply to comment #0) 3. Run ./configure --enable-threads --x-includes=/usr/X11R6 --x-libraries=/usr/X11R6 --with-cpu=powerpc --with-mpfr=/usr/local/lib --with-gmp=/usr/local/lib. Are you building in the

[Bug libfortran/26893] kinds.h not generated, causing failure

2006-07-13 Thread steven at gcc dot gnu dot org
--- Comment #18 from steven at gcc dot gnu dot org 2006-07-13 21:47 --- Re. comment #16: That looks like you get an internal compiler error (ICE )while building g++ which has nothing to do with libgfortran. If that ICE is reproducible, it deserves its own bug report. --

[Bug c++/28365] error: ' error: 'MyClass::MyClass(const MyClass)' is private error: within this context

2006-07-13 Thread kk at microfocus dot com
--- Comment #3 from kk at microfocus dot com 2006-07-13 21:49 --- (In reply to comment #2) If it is in our (Rogue Wave) current code, could you please let us know where so we can look into fixing it? (It's doesn't matter whther gcc does the right thing here or not, our code should be

  1   2   >