Re: var_args for rs6000 backend
From: Andrew Pinski <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Yao qi) CC: ian@airs.com, gcc@gcc.gnu.org Subject: Re: var_args for rs6000 backend Date: Fri, 9 Sep 2005 01:51:58 -0400 (EDT) > BTW, I am concerned about the value of TARGET_HARD_FLOAT and TARGET_FPRS, > I think both of them is 1 here, because I built GCC natively on POWER, but > when I trace > it , I found it skips this condation statement as if ARGET_HARD_FLOAT is 0, > I do not know > why. > > I have searched TARGET_HARD_FLOAT in GCC internals for GCC 3.3.5 and found > nothing about it. Could anyone tell me which file define these two macros? > > I grep it in gcc/config/rs6000/ but it seems that there is no file define > it. Could > anybody here have a look at it and verify it for me, any comments are highly > appreicated. TARGET_HARD_FLOAT is defined by the options generating file. So it is defined in rs6000.opt: mhard-float Target Report RejectNegative InverseMask(SOFT_FLOAT, HARD_FLOAT) Use hardware floating point Do you mean the value of TARGET_HARD_FLOAT is *1* when option -mhard-float is specified according to rs6000.opt ? I tried to specify this option and it seems useless to set TARGET_HARD_FLOAT. If so, that is to say, in rs6000_gimplify_va_arg() , the condations statement in line 5734, 5733 5734 if (TARGET_HARD_FLOAT && TARGET_FPRS 5735 && (TYPE_MODE (type) == SFmode || TYPE_MODE (type) == DFmode is *always* FALSE and all the float parameters wiil be passed in GPRs instead of FPRs. Am I right? Everyone here could verify or deny it, thanks in advance! But that does not sense as the default value for powerpc-linux-gnu is hard floats. Thanks Andrew Pinski Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: PATCH RFC: Proposed patch for PR c++/7874
[ Redirected from gcc-patches@ to gcc@ ]
Mark Mitchell <[EMAIL PROTECTED]> writes:
> This case is particularly tricky because of the fact that accepting
> the invalid code also means that we'll change the meaning of some
> valid code. For example, in:
>
> int f(int) {
>return 1;
> }
>
> struct S {
>friend int f(char) { return 2; }
> };
>
> int main () {
>return f('a');
> }
>
> we current return 2 from "main", which is incorrect. (Does your patch
> fix this, by the way? I'm not sure if we ever had the situation of an
> overload set in which some, but not all, functions were
> DECL_ANTICIPATED.)
Now that my patch handles the above case correctly, the test
g++.dg/template/friend10.C fails. And the original test case in PR
5116 fails.
I think the issue here is whether we should prefer an explicitly
declared conversion operator over a friend function found using
argument dependent lookup. With my current patch, we prefer the
conversion operator. (When friends are injected, we prefer the friend
function, which seems straightforward and correct.)
Can somebody with more C++-fu than I have take a look at these two
cases and see what is correct? Thanks.
Ian
Re: var_args for rs6000 backend
"Yao qi" <[EMAIL PROTECTED]> writes: > Do you mean the value of TARGET_HARD_FLOAT is *1* when option -mhard-float > is specified according to rs6000.opt ? Yes. TARGET_HARD_FLOAT is defined as #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) The -mhard-float option will clear the MASK_SOFT_FLOAT bit in target_flags. The default setting of the MASK_SOFT_FLOAT bit in target_flags depends upon the default processor. > If so, that is to say, in rs6000_gimplify_va_arg() , the condations > statement in > line 5734, >5733 >5734 if (TARGET_HARD_FLOAT && TARGET_FPRS >5735 && (TYPE_MODE (type) == SFmode || TYPE_MODE (type) == DFmode > > is *always* FALSE and all the float parameters wiil be passed in GPRs > instead of FPRs. > Am I right? Everyone here could verify or deny it, thanks in advance! The condition is not always false. The value depends on exactly how you have configured the compiler and exactly what options you pass. Ian
Re: Support for the MPC5554 in gcc ?
Hello! David Edelsohn wrote: Olivier Hainque writes: Olivier> Can GCC 4.X be used to generate code running properly on a MPC5554 Olivier> processor ? The base PowerPC Book-E UISA generated by GCC should work on the MPC5554. I am not sure about the difference between the 5554 e200 core and the 8540 e500 core. Kumar Gala at Freescale probably can provide more details about compatibility with GCC's e500 support and support in previous GCC releases. Maybe it's of any use: I've just compiled and installed the official gcc-3.4.4 release as a native compiler on an MPC8540 like that: $ gcc -v Reading specs from /usr/local/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,objc --enable-nls=yes --enable-clocale=gnu --disable-multilib --with-cpu=8540 Thread model: posix gcc version 3.4.4 I am not sure if that's all okay. We are planning to use the SPE (Signal Processing Engine (64bit vector operations (different to Altivec))) extension of the 8540. Before that we have had some compiling/runtime issues in Qt and our application with the prerelease (we'll check again): Configured with: ../gcc-3.4-20050422/configure --with-float=soft --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages="c,c++,objc" --enable-nls=yes --enable-clocale=gnu Thread model: posix gcc version 3.4.4 20050422 (prerelease) Best greets, Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Re: Support for the MPC5554 in gcc ?
Hello again! Olivier> Can GCC 4.X be used to generate code running properly on a MPC5554 Olivier> processor ? The base PowerPC Book-E UISA generated by GCC should work on the MPC5554. I am not sure about the difference between the 5554 e200 core and the 8540 e500 core. Oh, i've just seen that: http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf where it says on Page 12: The e200z6, implemented in the MPC5556 microcontroller, is code-compatible with e500 core (including isel, SPE, and single-precision floating-point APUs). Greets, Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
gcc-4.0-20050908 is now available
I do not know if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
should be fixed in this release, but I am sure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
which was marked as duplicate is not fixed:
[EMAIL PROTECTED]:~/projet/gujin$ cat > tmp.c
int
sub (int i)
{
int array[100] = { 0 };
sub2 (&array[i]);
}
[EMAIL PROTECTED]:~/projet/gujin$ ~/projet/toolchain/bin/gcc -S -Os tmp.c -o
tmp.s
[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.s
.file "tmp.c"
.section.rodata
.align 32
.type C.0.1134, @object
.size C.0.1134, 400
C.0.1134:
.zero 400
.text
.globl sub
.type sub, @function
sub:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl$400, %esp
pushl $400
pushl $C.0.1134
leal-404(%ebp), %ebx
pushl %ebx
callmemcpy
movl8(%ebp), %eax
leal(%ebx,%eax,4), %eax
pushl %eax
callsub2
addl$16, %esp
movl-4(%ebp), %ebx
leave
ret
.size sub, .-sub
.ident "GCC: (GNU) 4.0.2 20050908 (prerelease)"
.section.note.GNU-stack,"",@progbits
[EMAIL PROTECTED]:~/projet/gujin$
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
RE: var_args for rs6000 backend
From: "Meissner, Michael" <[EMAIL PROTECTED]> To: "Yao qi" <[EMAIL PROTECTED]> CC: gcc@gcc.gnu.org Subject: RE: var_args for rs6000 backend Date: Thu, 8 Sep 2005 21:19:25 -0400 Yes, the eABI is a modification of the System V ABI. IIRC (but it has been several years since I worked on PowerPC), the differences between eABI and System V were: 1) eABI used r2 as a secondary small data pointer (System V used just r13), and r0 was used for data centered around location 0; 2) there were some relocations in eABI not in System V (support for 3 small data pointers, section relative relocations) and some relocations in System V not in eABI (shared library support); 3) System V had 16-byte stack alignment and eABI had 8-byte stack alignment. I suspect there may be more changes that I'm forgetting about, and also the 64-bit support probably changes things also. Thanks very much for your explanation, and I will take them in mind. Now, I can understand the ideas about ABI clearly and map these ideas to the source code partialy. However, I am cofused by the combination of TREE operations, RTX and GIMPLE in the functions about variable arguments. I have to conquer them before I hack code about variable arguments in GCC, don't you? However my focus now is routines about variable argument, and do you think it is necessary for me to understand TREE strucuture, RTX and GIMPLE before I pay attention on variable arguments ? Is there any workrounds to bypass them partially? If there is no such shortcut for them, could you tell me how to start the learning in these fields ? Thank you very much again. Best Regards Yao Qi Bejing Institute of Technology _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
uncaught exception in g++ 3.4 and 4.0
There's a thread at
http://groups.google.co.uk/group/gnu.gcc.help/tree/browse_frm/thread/e85dce7d69fb7dc1
which looks odd. It seems that the exception filter is not being
correctly processed.
I can't find a Bugzilla entry for this. Is it really a bug?
Andrew.
quoted message
From: "Mark Nelson" <[EMAIL PROTECTED]>
Newsgroups: gnu.gcc.help
Subject: uncaught exception in g++ 3.4 and 4.0
Date: 13 Aug 2005 08:35:46 -0700
I have a case where an exception in the constructor of class with a
virtual base leads to termination:
struct vbase {};
struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";
}
};
main()
{
struct bar : public foo {};
try {
bar a;
}
catch ( ... ) {
}
return 0;
};
This program demonstrates the problem in g++ 3.4 a 4.0.0. Instead of
catching
the exception, the program terminates. The base dtor gets called as
expected, but upon return, there is some generated code that I can't
decipher, which jumps to some termination code at bad_alloc + 80.
That should be a clue... but I'm unable to catch it.
|
| mark
|
Re: var_args for rs6000 backend
Yes. TARGET_HARD_FLOAT is defined as #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) The -mhard-float option will clear the MASK_SOFT_FLOAT bit in target_flags. Yes, this option works when I use it in GDB like this, (gdb) run -mhard-float ../../gcc-dfp-cvs-Aung-10/gcc/testsuite/gcc.dg/dfp/qiyao/varargs-1.expand -o vararg-1.exe and TARGET_HARD_FLOAT becomes *TRUE*. Thanks. The default setting of the MASK_SOFT_FLOAT bit in target_flags depends upon the default processor. The condition is not always false. The value depends on exactly how you have configured the compiler and exactly what options you pass. Ian Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
gcc-4.1-20050909 is now available
Snapshot gcc-4.1-20050909 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050909/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-09-09 10:43 UTC You'll find: gcc-4.1-20050909.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050909.tar.bz2 C front end and core compiler gcc-ada-4.1-20050909.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050909.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050909.tar.bz2 C++ front end and runtime gcc-java-4.1-20050909.tar.bz2 Java front end and runtime gcc-objc-4.1-20050909.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050909.tar.bz2The GCC testsuite Diffs from 4.1-20050902 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
mips targets: seq_df, seq_sf
Please, explain, why mips.md specifies c.eq.d, c.eq.s instructions in seq_df and seq_sf RTF templates? Why not c.seq.d and c.seq.s? Seems, use of c.eq.d, c.eq.s causes violation of IEC 60559. Best regards, Nadezhda I. Vyukova
zero sized initializers with side effects discarded
Hello, In a number of places, the gimplifier simply discards what involves zero sized entities. For instance: in "gimplify_init_ctor_eval"... FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value) ... if (zero_sized_field_decl (purpose)) continue; or in "gimplify_modify_expr"... /* For zero sized types only gimplify the left hand side and right hand side as statements and throw away the assignment. */ if (zero_sized_type (TREE_TYPE (*from_p))) ... This is causing troubles when side effects are so discarded, for instance a call to a function returning a zero sized type. I have been experimenting with a simple patch adding side effects checks to the conditions, like "! TREE_SIDE_EFFECTS (value)" in init_ctor_eval and "! TREE_SIDE_EFFECTS (*from_p)" in modify_expr. The first programs in which I've observed problems were in Ada, and the patch helped them. Manual testing for C was not as successful (expected calls still missing), due to differences in the way TREE_SIDE_EFFECTS is set on various trees. Automated testing (make check) even triggered an ICE on zero-strct-4.c. Are the TREE_SIDE_EFFECTS checks mentioned above sensible ? I'd be happy to investigate further, provide testcases, work on extra patches, etc, and would welcome feedback first to ensure I'm searching in the right direction :) Thanks in advance for your advices, With Kind Regards, Olivier
Re: zero sized initializers with side effects discarded
On Sep 9, 2005, at 8:30 AM, Olivier Hainque wrote:
Hello,
I have been experimenting with a simple patch adding side effects
checks to the conditions, like "! TREE_SIDE_EFFECTS (value)"
in init_ctor_eval
Yes the one in needs to gimplify only the expression as a statement
and not add a modify statement. More on the testcase later.
and "! TREE_SIDE_EFFECTS (*from_p)" in modify_expr.
You should not need the check in modify_expr as the side effects are
never mishandled as we always will add the lhs and rhs to the
instruction stream:
/* For zero sized types only gimplify the left hand side and right
hand side
as statements and throw away the assignment. */
if (zero_sized_type (TREE_TYPE (*from_p)))
{
gimplify_stmt (from_p);
gimplify_stmt (to_p);
append_to_statement_list (*from_p, pre_p);
append_to_statement_list (*to_p, pre_p);
*expr_p = NULL_TREE;
return GS_ALL_DONE;
}
I already made sure of that because it was ran into with
some of the vararg testcases on some targets.
Now back to init_ctor_eval. Here is a testcase which should pass:
struct g{};
char y[3];
char *f = &y[0];
char *ff = &y[0];
struct h{struct g hhh; struct g hhh1;};
void h(void)
{
struct g t;
struct h t1 = {*((struct g*)(f++)), *((struct g*)(ff++))};
}
void abort (void);
int main(void)
{
h();
if (f != &y[1])
abort();
if (ff != &y[1])
abort();
return 0;
}
And it does for 2.95.3 but does not from 3.0.4 and up. It looks
like the front-end or somewhere else is messing it up before even
getting
to gimplifier. Also the ff test is actually working correctly too even
in 4.1.0 so I really doubt that init_ctor_eval is wrong any more.
If you want me to file a bug, I can, I can also look into the issue some
too and figure out where the f++ is going to. Note if we change struct
g
to be a non zero sized struct, it works.
-- Pinski
Re: zero sized initializers with side effects discarded
On Fri, 9 Sep 2005, Olivier Hainque wrote: Hello, In a number of places, the gimplifier simply discards what involves zero sized entities. For instance: in "gimplify_init_ctor_eval"... FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value) ... if (zero_sized_field_decl (purpose)) continue; or in "gimplify_modify_expr"... /* For zero sized types only gimplify the left hand side and right hand side as statements and throw away the assignment. */ if (zero_sized_type (TREE_TYPE (*from_p))) ... This is causing troubles when side effects are so discarded, for instance a call to a function returning a zero sized type. Even if you "fixed" init_ctor_eval (modify_expr gimplifies the lhs and rhs and throws away the assignment), you're going to run into problems in the subvar machinery if you really have 0 sized field accesses with side effects. I'm not sure what the heck a "0 sized field access with side effects" does. After all, a 0 sized field has no space, etc (in fact, it is nothing), so how could you side-effect by accessing one, since any such access must do nothing?
Re: zero sized initializers with side effects discarded
Daniel Berlin wrote:
> Even if you "fixed" init_ctor_eval (modify_expr gimplifies the lhs and rhs
> and throws away the assignment), you're going to run into problems in
> the subvar machinery if you really have 0 sized field accesses with side
> effects.
>
> I'm not sure what the heck a "0 sized field access with side effects"
> does.
>
> After all, a 0 sized field has no space, etc (in fact, it is nothing), so
> how could you side-effect by accessing one, since any such access must do
> nothing?
You may have side effect from an initializer when setting a zero
sized field.
For instance (variant of gcc.c-torture/compile/zero-strct-4.c), compiled
with GCC 3.4, the code below prints "returning raw_lock" as I would
expect. It doesn't print anything when compiled with mainline because
one_raw_spinlock is not called.
#include
typedef struct {} raw_spinlock_t;
typedef struct {
raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock (void)
{
raw_spinlock_t raw_lock;
printf ("returning raw_lock\n");
return raw_lock;
}
int main(void)
{
spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
return 0;
}
RE: zero sized initializers with side effects discarded
Original Message
>From: Olivier Hainque
>Sent: 09 September 2005 14:25
> You may have side effect from an initializer when setting a zero
> sized field.
>
> For instance (variant of gcc.c-torture/compile/zero-strct-4.c), compiled
> with GCC 3.4, the code below prints "returning raw_lock" as I would
> expect. It doesn't print anything when compiled with mainline because
> one_raw_spinlock is not called.
>
>#include
>
>typedef struct {} raw_spinlock_t;
>
>typedef struct {
> raw_spinlock_t raw_lock;
>} spinlock_t;
>
>
>raw_spinlock_t one_raw_spinlock (void)
>{
>raw_spinlock_t raw_lock;
>printf ("returning raw_lock\n");
>return raw_lock;
>}
Surely returning the vaule of this uninitialised variable makes your code
invalid?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: zero sized initializers with side effects discarded
>int main(void)
>{
> spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
What exactly is this code expected to do?
Call one_raw_spinlock and then throw away the result?
If so, feel free to change gimplify_init_ctor_eval to do that.
But again, if you expect "real" sets of zero sized fields to do
something, you are going to run into major issues.
Re: zero sized initializers with side effects discarded
Dave Korn wrote:
> Surely returning the vaule of this uninitialised variable makes your code
> invalid?
Well, sure. Adding an initializer in one_raw_spinlock doesn't help.
The t03.gimple dump reads:
main ()
{
struct spinlock_t D.1783;
int D.1784;
struct spinlock_t lock;
D.1784 = 0;
return D.1784;
}
Re: zero sized initializers with side effects discarded
Daniel Berlin <[EMAIL PROTECTED]> writes:
| >int main(void)
| >{
| > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
|
| What exactly is this code expected to do?
| Call one_raw_spinlock and then throw away the result?
yes, that is implied by C99 semantics.
-- Gaby
Re: zero sized initializers with side effects discarded
Daniel Berlin wrote:
> > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
>
> What exactly is this code expected to do?
> Call one_raw_spinlock and then throw away the result?
Yes. As you said, the result is nothing anyway, but the function should
still be called IMO.
> If so, feel free to change gimplify_init_ctor_eval to do that.
Thanks :)
Thanks for your feedback.
Olivier
g77 and PR21931
hi, if this bug get's fixed, will there be an upcoming release of gcc3.4 that could include it ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21931 it will be some work to figure it out, fix it, and make sure everyone is happy. i don't want to make that investment if it will not get out to the world at large; my personal situation is content with maintaining a local copy of g77 with the offending patche(s) reverted. my plan would be to contact all those who have expressed interest in this compiler option and make sure that all needs are addressed (if possible). --bud davis
Re: var_args for rs6000 backend
> Yao qi writes: >> Yes. TARGET_HARD_FLOAT is defined as >> >> #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0) >> >> The -mhard-float option will clear the MASK_SOFT_FLOAT bit in >> target_flags. Yao> Yes, this option works when I use it in GDB like this, Yao> (gdb) run -mhard-float Yao> ../../gcc-dfp-cvs-Aung-10/gcc/testsuite/gcc.dg/dfp/qiyao/varargs-1.expand -o Yao> vararg-1.exe Yao> and TARGET_HARD_FLOAT becomes *TRUE*. Thanks. This implies that you are developing and testing GCC with it configured incorrectly, unless you really want to test the behavior of DFP on GCC with no hardware (binary) floating point enabled. David
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
[EMAIL PROTECTED] wrote: Although many of us are involved, or have been involved, with other compiler projects, the focus of the Gelato GCC Improvement Group is to work *with* the GCC community *and* the GCC community *process* to improve GCC for Itanium. Some of the other projects which individuals are currently, or have been, involved with include OpenIMPACT , ORC , icc , LLVM , and a new initiative to produce a hybrid compiler based on the GCC front-end and the ORC back-end. (HP will present on this HP-led project in the general session at the next Gelato meeting.) It would be interesting to know more details about the hybrid compiler. - Will the backend use RTL, Tree-SSA or will the backend be just ORC backend with its IL? - If it is just ORC backend with own IL, who will support the hybrid compiler or you hope that gcc community will support two backends (ORC one for Itanium and gcc backend for other architectures)? - If you want to see the hybrid compiler as a part of gcc project, how are you going to solve the copyright problem? As I know, although ORC code is also distributed under GNU license, the copyright belongs to SGI. All code developed under gcc project should belong to FSF. Will SGI give up the copyright to FSF? So, if the hybrid compiler will use ORC backend as it exists, I am quite skeptical that the project will be viable. It will be just another research compiler, the users need an industrial compiler like gcc. There are a lot of technical problems too with usage of ORC backend (GCC supports many extensions like asm and languages). The ORC backend optimizations proven to work for Itanium could be rewritten for RTL with usage of existing gcc infrastructure, added to gcc and could be used for other ports. I think it is more right way to do. Vlad
Re: zero sized initializers with side effects discarded
Andrew Pinski wrote: > > I have been experimenting with a simple patch adding side effects > > checks to the conditions, like "! TREE_SIDE_EFFECTS (value)" > > in init_ctor_eval > > Yes the one in needs to gimplify only the expression as a statement > and not add a modify statement. More on the testcase later. > You should not need the check in modify_expr as the side effects are > never mishandled as we always will add the lhs and rhs to the > instruction stream: Oh, I see - misread what it did. Thanks. I was confused by the fact that the check in init_ctor_eval did not help for C while it did for Ada. It actually doesn't change the behavior for C (at least on my testcases) because we don't get into init_ctor_eval at all, but in gimplify_expr instead, which precisely processes values with TREE_SIDE_EFFECTS set. I'm not yet clear why the call is not issued there. This is my first dive in the gimplifier, so it might well be simple. > Here is a testcase which should pass: ... It doesn't pass with the init_ctor_eval check either. > If you want me to file a bug, I can, I can also look into the issue > some too and figure out where the f++ is going to. Either is fine with me (thanks for the offer :). On my side, I will test again with only the init_ctor_eval change and submit on gcc-patches with an Ada testcase. The only regressions I had with the two changes were the ICEs on zero-strct-4.c. I don't see them with the modify_expr change removed, so hopefully the second round will go well. > Note if we change struct g to be a non zero sized struct, it works. Indeed. Thanks for your feedback. Olivier
Re: Possible bug in tree-vrp.c:vrp_visit_phi_node
On 09/08/05 16:25, Laurent GUERBY wrote: FYI, this fixes both PR ada/23141 and ada/23142. Well, but I cannot get a clean bootstrap with it. It fails building libstdc++ on x86_64 and libgfortran on x86. I'll have to poke more.
smart memcpy
Hi all,
is it possible to map a region on memory copy on write using this idea?
I have an invalid argument in the mmap call.
Why?
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MAXPATH 255
int main (int argc, char **argv)
{
char *s,*x;
int i;
int addr;
int fd;
int size=40960;
char file_memory[MAXPATH];
pid_t p=getpid();
s=malloc(size);
sprintf(file_memory,"/proc/%d/mem",(int)p);
fd = open(file_memory,O_RDONLY);
if (fd < 0) {
perror(file_memory);
exit(-1);
}
printf ("start %s\n",file_memory);
printf("s = %p\n",s);
memset(s, 'X', size);
//lseek(fd,(int)s,SEEK_SET);
//read(fd,&addr,1);
//printf("%c", addr);
x = mmap(0,size,PROT_READ|PROT_WRITE,MAP_PRIVATE,fd,(int)s);
if ((int)(x)>0) {
printf("x = %p\n",x);
*x='P';
for (i=0;i<40; i++)
printf("sval=%c;xval=%c;",*(x+i),*(s+i));
} else {
printf("%s\n",strerror(errno));
}
return 0;
}
[PowerPC] PR23774 stack backchain broken saga
PR23774 shows a situation where powerpc-linux (and other rs6000 targets)
break an ABI requirement that 0(r1) always holds a pointer to the
previous stack frame, except for the topmost frame. This particular
case concerns dynamic stack (eg. alloca) deallocation. The other case
where this happens is __builtin_longjmp. It's easy to see why this
happens. restore_stack_block and restore_stack_nonlocal both write the
backchain after setting the new stack pointer.
Simply reordering the instructions doesn't cure the problem. Scheduling
conspires against us, and puts them back the other way. So we need some
sort of dependency or blockage to stop the scheduler reordering. I
tried a number of approaches.
1) First, I tried using emit_barrier() between the backchain write and
sp set. This failed on a testcase where the sp assignment was deleted,
leaving the barrier as the last insn. rs6000_output_function_epilogue
takes this to mean no epilogue is needed, so this idea doesn't work
unless you stop the stack pointer assignment being removed.
2) Next, I defined parallels to keep things together. Like the
following, with another for DImode.
(define_insn_and_split "set_stack_pointer_si"
[(set (mem:SI (match_operand:SI 1 "gpc_reg_operand" "b"))
(match_operand:SI 2 "gpc_reg_operand" "r"))
(set (match_operand:SI 0 "gpc_reg_operand" "=b")
(match_dup 1))]
"TARGET_32BIT"
"{st|stw} %2,0(%1)\;mr %0,%1"
"&& !TARGET_UPDATE"
[(set (mem:SI (match_dup 1)) (match_dup 2))
(set (match_dup 0) (match_dup 1))]
""
[(set_attr "type" "store")
(set_attr "length" "8")])
This works, but doesn't give ideal power4/5 insn grouping, with (I
think) one too many nops being emitted. Maybe that's a bug in the
bundling code, but trying to make it work with parallel's like the above
didn't seem a good idea.
3) Someone thought that setting the proper memory alias set for the mems
in these patterns would help. I tried that, it doesn't.
4) I used an unspec to make the sp assignment depend on the backchain
mem write.
;; Tie the update of sp to the write of the backchain word, so that the
;; backchain word is valid before sp is changed. If !TARGET_UPDATE
;; don't bother, since stack allocation isn't atomic.
(define_insn_and_split "*sp_"
[(set (match_operand:P 0 "gpc_reg_operand" "=b")
(unspec:P [(match_operand:P 1 "gpc_reg_operand" "r")
(match_operand:P 2 "memory_operand" "m")]
UNSPEC_SP))]
""
"mr %0,%1"
"&& !TARGET_UPDATE"
[(set (match_dup 0) (match_dup 1))]
"")
This also works, but give dismal results on power4/5. You get a bunch
of nops inserted, because mention of the mem in the unspec is taken to
mean that memory is read (duh!), and so store/load blockages need to be
avoided.
5) I used gen_stack_tie() in a similar approach to using
emit_barrier(). This too works, but again the MEMs in the stack_tie
insn are incorrectly interpreted as real memory accesses by the bundling
code, resulting in multiple unnecessary nops. I saw
lwz 0,0(1)
stw 0,0(10)
nop
nop
mr 1,10
nop
nop
being generated for restore_stack_block.
6) Finally, I tried a trick with a fake trap_if to ensure the scheduler
keeps what it thinks might be a trapping memory access, the backchain
write, before the stack pointer assignment. This also works, and gives
good results on power4/5. However, I'm not really that happy with this
idea since it relies on gcc rtl analysis staying sufficiently ignorant.
So I suspect I ought to go back to number (5), and make the bundling
code aware of stack_tie. It looks like this might be just a simple hack
to rs6000.c:get_next_active_insn. Comments? Oh, and BTW, why doesn't
get_next_active_insn discard BARRIER and CODE_LABEL?
diff -urp -xCVS -x'*~' -x'.#*' -xTAGS -xautom4te.cache -x'*.info'
gcc-virgin/gcc/config/rs6000/rs6000.md gcc-current/gcc/config/rs6000/rs6000.md
--- gcc-virgin/gcc/config/rs6000/rs6000.md 2005-09-01 20:15:50.0
+0930
+++ gcc-current/gcc/config/rs6000/rs6000.md 2005-09-09 15:54:01.0
+0930
@@ -9347,51 +9346,68 @@
""
"DONE;")
+;; The fake trap_if here makes the scheduler write out all mem that
+;; might trap. The idea is to ensure that the backchain word is written
+;; before sp is set. This scheme will fail if gcc is clever enough to
+;; figure out that the backchain write indeed cannot trap.
+(define_insn "*set_sp_"
+ [(set (match_operand:P 0 "gpc_reg_operand" "=b")
+ (match_operand:P 1 "gpc_reg_operand" "r"))
+ (trap_if (const_int 2) (const_int 0))]
+ ""
+ "mr %0,%1")
+
(define_expand "restore_stack_block"
- [(use (match_operand 0 "register_operand" ""))
- (set (match_dup 2) (match_dup 3))
- (set (match_dup 0) (match_operand 1 "register_operand" ""))
- (set (match_dup 3) (match_dup 2))]
+ [(set (match_dup 2) (match_dup 3))
+ (set (match_dup 4) (match_dup 2))
+ (parallel [(set (match_operand 0 "register_
Re: PATCH RFC: Proposed patch for PR c++/7874
Ian Lance Taylor wrote: > Now that my patch handles the above case correctly, the test > g++.dg/template/friend10.C fails. And the original test case in PR > 5116 fails. > > I think the issue here is whether we should prefer an explicitly > declared conversion operator over a friend function found using > argument dependent lookup. With my current patch, we prefer the > conversion operator. (When friends are injected, we prefer the friend > function, which seems straightforward and correct.) > > Can somebody with more C++-fu than I have take a look at these two > cases and see what is correct? Thanks. Let's start with the simpler friend10.C. There, the "operator bool()" conversion operator is irrelevant, as far as I can see. However, we *should* still call the friend operator<<, because argument-dependent lookup is explicitly defined that way. So, in that particular form of lookup, you should ignore DECL_ANTICIPATED -- but only if the friend was declared in one of the classes that's in the set of special classes. I guess, without changing our representation, you get to go through each of the DECL_ANTICIPATED friends, and then call is_friend (fn, c) for each c in the set of argument-dependent classes. That's wort-case quadratic, and we could make it cleverer, but I'd start with that. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
sh64 support deteriorating
I can't justify spending the amount time that it would take to make the sh64 port regression free. The lack of a debugger that works reliably with recent gcc versions has led to an increasing backlog of uninvestigated execution failures.
Re: sh64 support deteriorating
Joern RENNECKE <[EMAIL PROTECTED]> wrote: > I can't justify spending the amount time that it would take to make the > sh64 port regression free. > The lack of a debugger that works reliably with recent gcc versions has > led to an increasing > backlog of uninvestigated execution failures. For reference, could you post some regression results to gcc-testresults? -- Giovanni Bajo
question about linker
Hi
I am looking for the source code related to linking stage--coz I am trying
to modify (very slightly) the linker. I understand that 'ld' is the linker
in Linux. My question is:
Is 'ld' a part of gcc toolchain?
--If it is, I should be able to find source file producing 'ld'. But I
haven't found the source file to be compiled to 'ld'.
--If it's not, main() of gcc.c should invoke ld if it found the '-o' option.
But I didn't find the invocation either(maybe it's not a straightforward
invocation).
Can someone show me where should I start to investigate it? Thanks a lot,
Shuo
Here is something I thought related, but I think it is not directly related
to linking stage.
6615 if (! strcmp (linker_name_spec, "collect2"))
6616 {
6617 char *s = find_a_file (&exec_prefixes, "collect2", X_OK, 0);
6618 if (s == NULL)
6619 linker_name_spec = "ld";
6620 }
_
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
mirror question
hey i could become a mirror if you want i'm from rome italy the server is in Arezzo Italy i have 3 domains that you could mirror though if u wanted let me know please :) win.ac3bf1.com lnx.ac3bf1.com rjn.it P.S. = send me the files to upload right away if u want or tell me what u want 2 upload (and from where to get it) to upload it ;) so i'll do it asap :P jonathan
RE: var_args for rs6000 backend
As I said, I haven't looked at the code in awhile (before GIMPLE), but the TREE code is the symbol table that allows you to look up the types of arguments and the function return type. The RTX code are the instructions you produce for va_arg, etc. For example, I believe the eabi/System V had a structure that had a few elements, one of which was the argument number, then there pointers to the save areas for gpr and fpr registers and the stack frame. The va_arg code would have to produce code that tested the argument number, and if it was the first 8 arguments it would use the pointer to the gpr/fpr save areas and if not it would use the stack pointer, and finally bump up the argument number. I may be somewhat wrong on the details. That is the trouble on working on quite a few different ports -- after awhile all of the details blend together. -Original Message- From: Yao qi [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 6:43 AM To: Meissner, Michael Cc: gcc@gcc.gnu.org Subject: RE: var_args for rs6000 backend >From: "Meissner, Michael" <[EMAIL PROTECTED]> >To: "Yao qi" <[EMAIL PROTECTED]> >CC: gcc@gcc.gnu.org >Subject: RE: var_args for rs6000 backend >Date: Thu, 8 Sep 2005 21:19:25 -0400 > >Yes, the eABI is a modification of the System V ABI. IIRC (but it has >been several years since I worked on PowerPC), the differences between >eABI and System V were: > >1) eABI used r2 as a secondary small data pointer (System V used just >r13), and r0 was used for data centered around location 0; > >2) there were some relocations in eABI not in System V (support for 3 >small data pointers, section relative relocations) and some relocations >in System V not in eABI (shared library support); > >3) System V had 16-byte stack alignment and eABI had 8-byte stack >alignment. > >I suspect there may be more changes that I'm forgetting about, and also >the 64-bit support probably changes things also. > Thanks very much for your explanation, and I will take them in mind. Now, I can understand the ideas about ABI clearly and map these ideas to the source code partialy. However, I am cofused by the combination of TREE operations, RTX and GIMPLE in the functions about variable arguments. I have to conquer them before I hack code about variable arguments in GCC, don't you? However my focus now is routines about variable argument, and do you think it is necessary for me to understand TREE strucuture, RTX and GIMPLE before I pay attention on variable arguments ? Is there any workrounds to bypass them partially? If there is no such shortcut for them, could you tell me how to start the learning in these fields ? Thank you very much again. Best Regards Yao Qi Bejing Institute of Technology _ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Re: question about linker
On Sep 9, 2005, at 10:28 AM, sean yang wrote: Hi I am looking for the source code related to linking stage--coz I am trying to modify (very slightly) the linker. I understand that 'ld' is the linker in Linux. My question is: Is 'ld' a part of gcc toolchain? --If it is, I should be able to find source file producing 'ld'. But I haven't found the source file to be compiled to 'ld'. --If it's not, main() of gcc.c should invoke ld if it found the '- o' option. But I didn't find the invocation either(maybe it's not a straightforward invocation). The linker is ld, and is in the binutils package. http:// sourceware.org/binutils/. To see what's really going on try adding -v and -Wl,-v to your gcc command line. -eric
Re: question about linker
> Is 'ld' a part of gcc toolchain? See http://sources.redhat.com/binutils/ >6617 char *s = find_a_file (&exec_prefixes, "collect2", X_OK, 0); collect2 is a wrapper around ld which invokes ld twice if needed - once to gather information, and a second time with an additional object it generates that supports some of the features gcc provides which need to know about all the symbols in the file.
Re: Question regarding compiling a toolchain for a Broadcom SB1
= Both binutils and glibc's configure scripts will see it as a mips32, because it does not start off with mips64 in the name. Should probably fix the configury to recognize mipsisa64 as a 64-bit target. binutils should already do this for mipsisa64-linux-gnu, but I don't know about current glibc. -eric
Re: PATCH RFC: Proposed patch for PR c++/7874
Mark Mitchell <[EMAIL PROTECTED]> writes: > Let's start with the simpler friend10.C. There, the "operator bool()" > conversion operator is irrelevant, as far as I can see. However, we > *should* still call the friend operator<<, because argument-dependent > lookup is explicitly defined that way. > > So, in that particular form of lookup, you should ignore > DECL_ANTICIPATED -- but only if the friend was declared in one of the > classes that's in the set of special classes. I guess, without changing > our representation, you get to go through each of the DECL_ANTICIPATED > friends, and then call is_friend (fn, c) for each c in the set of > argument-dependent classes. That's wort-case quadratic, and we could > make it cleverer, but I'd start with that. Thanks for the analysis. Naturally, addressing that issue caused another problem, namely g++.old-deja/g++.jason/scoping15.C. Because the call to imag in that test case is written ::imag, the parser does not do argument dependent lookup to find the function. So the compiler looks for a top-level declaration for ::imag, and doesn't find one. So, if we only do argument dependent lookup for unqualified names, and we only find otherwise-undeclared friend functions using argument dependent lookup, then is scoping15.C correct C++ or not? Thanks for any insight on this one. Ian
Re: PATCH RFC: Proposed patch for PR c++/7874
Ian Lance Taylor wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > >>Let's start with the simpler friend10.C. There, the "operator bool()" >>conversion operator is irrelevant, as far as I can see. However, we >>*should* still call the friend operator<<, because argument-dependent >>lookup is explicitly defined that way. >> >>So, in that particular form of lookup, you should ignore >>DECL_ANTICIPATED -- but only if the friend was declared in one of the >>classes that's in the set of special classes. I guess, without changing >>our representation, you get to go through each of the DECL_ANTICIPATED >>friends, and then call is_friend (fn, c) for each c in the set of >>argument-dependent classes. That's wort-case quadratic, and we could >>make it cleverer, but I'd start with that. > > > Thanks for the analysis. > > Naturally, addressing that issue caused another problem, namely > g++.old-deja/g++.jason/scoping15.C. That case is not valid C++. Probably, you should add -ffriend-inject to the test case; that will test that the new switch does what it should! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
On Fri, Sep 09, 2005 at 10:47:43AM -0400, Vladimir N. Makarov wrote: > - If you want to see the hybrid compiler as a part of gcc project, how > are you going to solve the copyright problem? As I know, although ORC > code is also distributed under GNU license, the copyright belongs to > SGI. All code developed under gcc project should belong to FSF. Will > SGI give up the copyright to FSF? It's possible that the FSF would accept some other legal arrangement than a copyright assignment, but that would be up to the FSF and SGI to negotiate.
Re: gcc-4.0-20050908 is now available
Etienne Lorrain <[EMAIL PROTECTED]> writes: > I do not know if > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477 > should be fixed in this release, but I am sure > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631 > which was marked as duplicate is not fixed: According to the PR, the bug is fixed in 4.1. You are testing a gcc-4.0 snapshot. Try testing a gcc-4.1 snapshot. Ian
Re: zero sized initializers with side effects discarded
On Sep 9, 2005, at 4:40 PM, Olivier Hainque wrote:
Olivier Hainque wrote:
I'm not yet clear why the call is not issued there. This is my first
dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, despite the presence of a function call in
the components.
No, that is not the problem. The problem is that we gimplify the
expression for side effects but don't actually add the expression
if the gimplify put it back in the same expression.
Any ways, the following patch fixes the issue correctly.
If you could test and post the patch, that would be nice?
Thanks,
Andrew Pinski
ChangeLog:
* gimplify.c (gimplify_expr) : Add the
expressions to a statement list instead of gimplifying them.
Index: gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.151
diff -u -p -r2.151 gimplify.c
--- gimplify.c 6 Sep 2005 02:04:51 - 2.151
+++ gimplify.c 9 Sep 2005 21:22:42 -
@@ -4199,18 +4199,19 @@ gimplify_expr (tree *expr_p, tree *pre_p
{
unsigned HOST_WIDE_INT ix;
constructor_elt *ce;
+ tree temp = NULL_TREE;
for (ix = 0;
VEC_iterate (constructor_elt, CONSTRUCTOR_ELTS (*expr_p),
ix, ce);
ix++)
if (TREE_SIDE_EFFECTS (ce->value))
- gimplify_expr (&ce->value, pre_p, post_p,
-gimple_test_f, fallback);
+ append_to_statement_list (ce->value, &temp);
- *expr_p = NULL_TREE;
+ *expr_p = temp;
+ ret = GS_OK;
}
-
- ret = GS_ALL_DONE;
+ else
+ ret = GS_ALL_DONE;
break;
/* The following are special cases that are not handled by the
Re: zero sized initializers with side effects discarded
On Sep 9, 2005, at 4:40 PM, Olivier Hainque wrote: Olivier Hainque wrote: I'm not yet clear why the call is not issued there. This is my first dive in the gimplifier, so it might well be simple. FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not set on the constructor, despite the presence of a function call in the components. I will take look into this, it might be just a simple gimplify_stmt on the right hand side of the constructor. -- Pinski
Re: zero sized initializers with side effects discarded
Olivier Hainque wrote: > I'm not yet clear why the call is not issued there. This is my first > dive in the gimplifier, so it might well be simple. FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not set on the constructor, despite the presence of a function call in the components.
Re: uncaught exception in g++ 3.4 and 4.0
On Fri, Sep 09, 2005 at 11:57:07AM +0100, Andrew Haley wrote: > I can't find a Bugzilla entry for this. Is it really a bug? You'd have to get a c++ ruling to be sure, but from the code that makes it to the middle end, it's not a bug. The main::bar::bar() constructor catches the throw from the foo() constructor and calls __cxa_call_unexpected to abort. r~
Re: [PowerPC] PR23774 stack backchain broken saga
On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote: > 2) Next, I defined parallels to keep things together. Like the > following, with another for DImode. This seems most reasonable to me. > This works, but doesn't give ideal power4/5 insn grouping, with (I > think) one too many nops being emitted. Who cares? This is after a longjmp isn't it? r~
Re: sh64 support deteriorating
On Fri, Sep 09, 2005 at 04:58:50PM +0100, Joern RENNECKE wrote: > The lack of a debugger that works reliably with recent gcc versions has > led to an increasing backlog of uninvestigated execution failures. Do you think it's the debugger or the compiler that's at fault? r~
RE: gcc-4.0-20050908 is now available
Ian Lance Taylor wrote: > According to the PR, the bug is fixed in 4.1. You are testing a > gcc-4.0 snapshot. Try testing a gcc-4.1 snapshot. Then he's saying this is still a regression in gcc-4.0?
Re: [PowerPC] PR23774 stack backchain broken saga
On Fri, Sep 09, 2005 at 05:03:48PM -0700, Richard Henderson wrote: > On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote: > > 2) Next, I defined parallels to keep things together. Like the > > following, with another for DImode. > > This seems most reasonable to me. > > > This works, but doesn't give ideal power4/5 insn grouping, with (I > > think) one too many nops being emitted. > > Who cares? This is after a longjmp isn't it? Also stack deallocation when finished with alloca memory. For some reason 4.0/4.1 doesn't combine this deallocation with stack adjustment in the epilogue, a regression from 3.4. -- Alan Modra IBM OzLabs - Linux Technology Centre
Re: [PowerPC] PR23774 stack backchain broken saga
On Sat, Sep 10, 2005 at 12:57:49PM +0930, Alan Modra wrote: > Also stack deallocation when finished with alloca memory. Ah. > For some reason 4.0/4.1 doesn't combine this deallocation with > stack adjustment in the epilogue, a regression from 3.4. Yeah, I've been meaning to write a pass that goes through and figures out when the deallocations can be removed. I keep forgetting. r~
