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
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
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
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
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
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++
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)
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
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
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
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
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:
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
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
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
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
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
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
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
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?
--
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.
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
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
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:
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
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
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?
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,
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
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
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:
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
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 -
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 -
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
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
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
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
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
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
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
-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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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?
--- 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.
--
--- 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
--- 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
../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,
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 ***
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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'
--- 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
--- 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;
}
--- 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
--- 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,
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
--- 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
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
--- 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
--- 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()
--- 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
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
--- 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
--- 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)
--- 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))
--- 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
--- 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
--
--- 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
--- 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
--
--- 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:
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
--- 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
--- 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
--- 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
--- 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
--- 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.)
--- 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
--- 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
/* 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:
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
--- 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
--- 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
--- 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?
--
--- 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
--- 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.
--
--- 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 - 100 of 116 matches
Mail list logo
