'main' enters in gcc-4.1
Hello,
I'm using '-finstrument-functions' for a while
to make function-level profiling.
Recently, I compiled gcc-4.1 (without problem)
and used it for the same purpose.
Here is the result :
Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=0
Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=0
Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=6
Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=176
Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=0
Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
Enter orig (essai.c:23) [0x8048f20] from 0x8049448 - PID=1774 - elaps=1
(...)
Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=198
This test program is a very small C program with 'main' calling two
functions
in a loop, compiled with -O2. These messages are generated by my
__cyg_profile_{enter|exit} functions.
as you can see GCC generates 3 consecutive calls to 'main', then 2
exits, 2 enters,
and 2 exits.
At last it is coherent, but the behavior does not appear in older
versions of GCC.
Can you explain me why I see that behavior ? Is it "good" or is it a bug ?
Of cours this is a little disturbing for people that make the assumption
that
'main' is called once :o)
Thanks in advance.
Regards,
--
Yannick Perret
Re: sparc-linux results for 4.0.1 RC3
On 7/6/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > On 7/6/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > > Christian Joensson wrote: > > > > >limiting this e-mail... I could also rebootstrap 4.0.0 if you think > > >that'd be more useful... let me know what you would like... > > > > > Well, every possible independent check can be useful. Both > > rebootstrapping 4.0.0 with your exact current machine certainly makes > > sense (maybe it's obvious to you but for this kind of work, it suffices > > a simple 'make' and only --enable-languages=c++, will take *a lot* less > > time) and testing 4.0.1 with a machine as similar as possible to the one > > you used at the time for 4.0.0. > > > > Also, of course I would like to see the libstdc++.log bits for the fails. > > so, 4.0.0 c++ only is on the way... and here's the relevant(?) > libstdc++.log bits: So, 4.0.0 testsuite posted at: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00344.html What would you like me to do now? I could back off binutils to binutils-2.15.92.0.2-5 and rebootstrap both 4.0.0 and 4.0.1 RC3 for c++ only... -- Cheers, /ChJ
Stage 2 ends?
Mark, I have a simple C++ patch which I need to clean up for submission (it makes us not print default arguments for template parameters in diagnostics, which is much requested from the Boost community). It doesn't qualify for Stage 3 though, so I would like to know what's the current status of Stage 2. As things stand now, Stage 2 ends tomorrow. Giovanni Bajo
Re: GCC 4.0.1 RC3
Mark Mitchell <[EMAIL PROTECTED]> wrote: > GCC 4.0.1 RC3 is now available here: > >ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ > > With luck, this will be the last 4.0.1 release candidate. > > Please do download tarballs from the above URL and confirm that they > work OK on your systems. sh4-unknown-linux-gnu is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00354.html Regards, kaz
[PATCH] Modify MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX
Hi,
As previously discussed, we would need to modify MEMBER_TYPE_FORCES_BLK on
IA-64/HP-UX to make the Ada compiler work there. The typical testcase is:
package z is
type Integer_3_Spec is range -2..2;
for Integer_3_Spec'Size use 3;
type Enum_2_Spec is (Red, Orange, Yellow);
for Enum_2_Spec'Size use 2;
type Rec_3_Spec is record
x,y,z : Boolean;
end record;
pragma Pack(Rec_3_Spec);
for Rec_3_Spec'Size use 3;
type Rec_10_Spec is
record
B1, B2, B3, B4, B5, B6, B7, B8, B9, B10: Boolean;
end record;
pragma Pack(Rec_10_Spec);
for Rec_10_Spec'Size use 10;
type Rec_27_Spec is
record
X1, X2, X3: Rec_3_Spec;
X4, X5: Integer_3_Spec;
Two_Bits: Enum_2_Spec;
Ten_Bits: Rec_10_Spec;
end record;
pragma Pack(Rec_27_Spec);
for Rec_27_Spec'Size use 27;
end z;
Currently this doesn't compile on IA-64/HP-UX because the compiler cannot
fulfill the size representation clause for Rec_27_Spec, as it cannot
sufficiently pack the components of the record type. Technically this
happens because some of them are given BLKmode and BLKmode basically means
alignment on byte boundaries.
The main change would read:
--- config/ia64/hpux.h 25 Jun 2005 01:21:26 - 1.53
+++ config/ia64/hpux.h 7 Jul 2005 10:37:07 -
@@ -106,14 +106,7 @@ do {
\
#define TARGET_DEFAULT \
(MASK_DWARF2_ASM | MASK_BIG_ENDIAN | MASK_ILP32)
-/* This needs to be set to force structure arguments with a single
- integer field to be treated as structures and not as the type of
- their field. Without this a structure with a single char will be
- returned just like a char variable, instead of being returned at the
- top of the register as specified for big-endian IA64. */
-
-#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE) \
- (!FLOAT_MODE_P (MODE) || (MODE) == TFmode)
+#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE) ((MODE) == TFmode)
Running the gcc.dg/compat/compat.exp testsuite between the unpatched and the
patched mainline compiler shows no failures; that's sufficient to prove that
the first part of the macro is now useless to implement the big-endian
calling conventions.
Running the gcc.dg/compat/struct-layout-1 testsuite between the unpatched and
the patched mainline compiler shows several failures, but most of them are
duplicates of the existing failures
FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t021 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o
execute
that are present even when the unpatched mainline compiler is confronted with
itself.
There are a few new failures though, which pertain to the calling conventions
for structures containing zero-sized unions and structures and a unique FP
field:
struct { struct {} a; float f; };
They are currently passed in general registers (because they are given BLKmode
by compute_record_mode), they would now be passed in FP registers (because
they would be given FP mode).
This kind of structures are GNU extensions (the HP compiler rejects them) so
it could be deemed acceptable to break binary compatibility here. However it
is relatively easy to patch ia64_function_arg to counter the macro change.
The patch was bootstrapped/regtested/compat-regtested on ia64-hp-hpux11.23.
2005-07-07 Eric Botcazou <[EMAIL PROTECTED]>
* config/ia64/hpux.h (MEMBER_TYPE_FORCES_BLK): Only force
TFmode to BLKmode.
* config/ia64/ia64.c (force_general_reg): New function.
(ia64_function_arg): Pass the argument in general regs
if force_general_reg returns true.
--
Eric Botcazou
Index: config/ia64/hpux.h
===
RCS file: /cvs/gcc/gcc/gcc/config/ia64/hpux.h,v
retrieving revision 1.53
diff -u -p -r1.53 hpux.h
--- config/ia64/hpux.h 25 Jun 2005 01:21:26 - 1.53
+++ config/ia64/hpux.h 7 Jul 2005 11:34:32 -
@@ -106,14 +106,7 @@ do { \
#define TARGET_DEFAULT \
(MASK_DWARF2_ASM | MASK_BIG_ENDIAN | MASK_ILP32)
-/* This needs to be set to force structure arguments with a single
- integer field to be treated as structures and not as the type of
- their field. Without this a structure with a sin
Re: Existing tree functionality?
On Thu, Jul 07, 2005 at 09:31:35AM -0400, Michael Tegtmeyer wrote: > I'm getting crashes for non-trivial code-mostly templates-that > otherwise compiles fine. Am I missing something? Does something else need > to be scheduled before pass_reference_vars? > You would have to show us your patch and the failing test case. This is too vague for me to know what may be wrong. If you are not modifying the IL, then it looks like your pass_foo is doing something wonky. Diego.
Re: Existing tree functionality?
I'm using gcc initially to do some static analysis with the resuts being sent somewhere else for the time being. I basically just need to gather the variables with visibility outside of the current function. In addition I need as little tree transformation prior to this collection as possible-ie introduction of new temporaries etc. I scheduled a new pass before pass_all_optimizations that simply has pass_referenced_vars and pass_foo as subpasses where pass_foo does the analysis (simply calls debug_referenced_vars() for the moment). Things seem to work for the most part but I'm getting crashes for non-trivial code-mostly templates-that otherwise compiles fine. Am I missing something? Does something else need to be scheduled before pass_reference_vars? I'm using the release version of gcc-4 because I didn't feel like chasing a moving target but is this a known issue where I should be building against the snapshot? Thanks again, Mike Tegtmeyer BTW Diego, I spent about a year doing OpenMP work using your CSSAME library. Small world eh? Thanks-intraprocedural is all I need. Sorry, bit new to gcc internals (coming from SUIF), is anything missing from referenced_vars list or is it complete? docs in tree-dfa.c state that it doesn't look in statement operands. Does it just collect this from the symbol tables? No. It collects only the variables that are actually referenced in the function body. If you give us a few details of what you're looking for, we can probably help you better. Diego.
Re: Existing tree functionality?
On Thu, 2005-07-07 at 09:31 -0400, Michael Tegtmeyer wrote: > I'm using gcc initially to do some static analysis with the resuts being > sent somewhere else for the time being. I basically just need to gather > the variables with visibility outside of the current function. In addition > I need as little tree transformation prior to this collection as > possible-ie introduction of new temporaries etc. I scheduled a new pass > before pass_all_optimizations that simply has pass_referenced_vars and > pass_foo as subpasses where pass_foo does the analysis (simply calls > debug_referenced_vars() for the moment). pass_init_datastructures is still necessary. If that is being called, then it is likely your code that is doing something broken, since, as you've said, it works fine otherwise :)
Re: GCC 4.0.1 RC3
Kaz Kojima wrote: Mark Mitchell <[EMAIL PROTECTED]> wrote: GCC 4.0.1 RC3 is now available here: ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ With luck, this will be the last 4.0.1 release candidate. Please do download tarballs from the above URL and confirm that they work OK on your systems. sh4-unknown-linux-gnu is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00354.html Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Existing tree functionality?
pass_init_datastructures is still necessary.
That was the problem-thanks.
New question (or still the original rather), is there existing
functionality to obtain the variables used in a function with external
visibility for that function-or in other words-any variable not local to
that function? is_global_vars() works for globals but misses:
struct foo {
int i;
void bar() {i=10;}
};
In bar, 'i' is not global but is not passed in via arguments either.
referenced_vars contains the 'this' ptr. Is there anything existing that
will obtain 'i' as an external variable w.r.t. bar?
Thanks again,
Mike
Re: Existing tree functionality?
On Thu, Jul 07, 2005 at 12:40:11PM -0400, Michael Tegtmeyer wrote: > In bar, 'i' is not global but is not passed in via arguments either. > referenced_vars contains the 'this' ptr. Is there anything existing that > will obtain 'i' as an external variable w.r.t. bar? > 'i' is not a standalone variable, it's a field of struct foo. 'this' is a PARM_DECL. 'this->i' is external to bar. Diego.
Re: Existing tree functionality?
On Thu, 2005-07-07 at 12:40 -0400, Michael Tegtmeyer wrote:
> > pass_init_datastructures is still necessary.
>
> That was the problem-thanks.
>
> New question (or still the original rather), is there existing
> functionality to obtain the variables used in a function with external
> visibility for that function-or in other words-any variable not local to
> that function? is_global_vars() works for globals but misses:
>
> struct foo {
> int i;
> void bar() {i=10;}
> };
> In bar, 'i' is not global but is not passed in via arguments either.
> referenced_vars contains the 'this' ptr.
i is not a regular variable here, it's a member of a structure.
> Is there anything existing that
> will obtain 'i' as an external variable w.r.t. bar?
No, but only because it's not really a variable, it's a structure
member, and only ever accessed as such. It thus doesn't appear as a
VAR_DECL (in gcc terms), it appears in component accesses as a
FIELD_DECL.
>
> Thanks again,
> Mike
RE: GCC 4.0.1 RC3
Original Message >From: Mark Mitchell >Sent: 03 July 2005 19:21 > GCC 4.0.1 RC3 is now available here: > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00373.html Cygwin's ok. Still some apparent g++ regressions, relative to 4.0.0, but everything's better than 4.0.1 RC1's results. [EMAIL PROTECTED] tsts]$ diff b4.txt af.txt 10a11,12 > FAIL: g++.dg/template/repo1.C (test for excess errors) > FAIL: g++.dg/template/repo3.C (test for excess errors) 30a33,38 > FAIL: g++.old-deja/g++.pt/instantiate4.C (test for excess errors) > FAIL: g++.old-deja/g++.pt/instantiate6.C (test for excess errors) > FAIL: g++.old-deja/g++.pt/repo1.C (test for excess errors) > FAIL: g++.old-deja/g++.pt/repo2.C (test for excess errors) > FAIL: g++.old-deja/g++.pt/repo3.C (test for excess errors) > FAIL: g++.old-deja/g++.pt/repo4.C (test for excess errors) No other significant changes to report. I have really no knowledge of what's going on here with templates and repositories; do you want to see the .log file? cheers, DaveK -- Can't think of a witty .sigline today
Re: draft release notes for 4.0.1
Joe Buck wrote: It's BCK Thanks! The list will be converted to HTML (I have a Perl script to do most of the work, but it then requires a bit of hand-tweaking of the output) and will be added to http://gcc.gnu.org/gcc-4.0/changes.html . How quickly could you do that conversion? I'm about to start working on rolling the release, so if unless you get back to me right away, we'll just add this to the web site later. That's OK; it just means the documentation generated with the release itself will not have the list. 21523 [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux 21551 ia64-unknown-linux-gnu ia64 bootstrap failed I'm virtually certainly that 21523 was not present in 4.0.0. I'm not sure about the other. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Existing tree functionality?
struct foo {
int i;
void bar() {i=10;}
};
i is not a regular variable here, it's a member of a structure.
Agreed.
No, but only because it's not really a variable, it's a structure
member, and only ever accessed as such. It thus doesn't appear as a
VAR_DECL (in gcc terms), it appears in component accesses as a
FIELD_DECL.
Sorry, I'm still pretty new to the tree layout. So what is the easiest way
to access this? referenced_vars returns the 'this' variable which is
obviously a structure. My understanding is that I can access it's fields
with the facilities available but 'i' is what was specifically
referenced - not all of the fields. So the question is, what is the
easiest way to obtain the specific field that was referenced in this case?
Re: Existing tree functionality?
On Thu, Jul 07, 2005 at 01:28:18PM -0400, Michael Tegtmeyer wrote: > So the question is, what is the easiest way to obtain the > specific field that was referenced in this case? > You need to traverse the IL and examine the LHS and RHS of expressions for COMPONENT_REF and INDIRECT_REF expressions. In GIMPLE these expressions may only appear on the LHS or RHS of assignments, and in function arguments. You then need to walk the expression looking for FIELD_DECLs. And you had better do this before SRA (which will decompose most structure references into compiler generated scalars). Diego.
Inappropriate ChangeLog entry
Feng -- Thank you for your contributions to GNU Fortran. It was brought to my attention that the CVS log for fortran/ChangeLog contains the following: For the 60th anniversary of Chinese people??s Anti-Japan war victory. associated with your recent check-in. The GNU Project, in general, and GCC, in particular, transcend national boundaries. National politics have no place here; in the context of GCC, at least, we are all united in the common goal of building a great compiler. Please do not check in any similar comments in the future. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Stage 2 ends?
Giovanni Bajo wrote: Mark, I have a simple C++ patch which I need to clean up for submission (it makes us not print default arguments for template parameters in diagnostics, which is much requested from the Boost community). It doesn't qualify for Stage 3 though, so I would like to know what's the current status of Stage 2. As things stand now, Stage 2 ends tomorrow. Yes; Stage 2 will indeed end tomorrow. However, I've been trying to give more discretion to maintainers of back ends and languages to accept patches that they are convinced are safe, sane, and highly worthwhile. So, I think you might still get your patch into 4.1, if you're lucky. Then again, there are a lot of regression in 4.[01] at this point, so the Boost folks might appreciate you fixing some of those as well. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [PATCH] Modify MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX
On Thu, 2005-07-07 at 05:02, Eric Botcazou wrote: > * config/ia64/hpux.h (MEMBER_TYPE_FORCES_BLK): Only force > TFmode to BLKmode. > * config/ia64/ia64.c (force_general_reg): New function. > (ia64_function_arg): Pass the argument in general regs > if force_general_reg returns true. This is OK with me. Presumably we should wait for a comment from Steve, as ia64-hpux is more his port than mine. You probably meant to send this to the gcc-patches list. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [PATCH] Modify MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX
> This is OK with me. Thanks. > Presumably we should wait for a comment from Steve, as ia64-hpux is more his > port than mine. Sure. > You probably meant to send this to the gcc-patches list. Yes. :-) Pilot error... -- Eric Botcazou
RFA: -mfpmath=sse -fpic vs double constants
Compiling a simple function like
double foo(double x) { return x+1.0; }
on x86 with -O2 -march=pentium4 -mtune=prescott -mfpmath=sse -fpic, the
load of 1.0 is done as
cvtss2sd[EMAIL PROTECTED](%ecx), %xmm0
(this is Linux, the same happens on Darwin).
This is not really a good idea, as movsd of a double-precision 1.0 is
faster.
The change from double to single precision is done in
compress_float_constant,
and there's no cost computation there; presumably the RTL optimizers
are expected
to change it back if that's beneficial.
Without -fpic, this does happen in cse_insn. (mem/u/i:SF
(symbol_ref/u:SI ("*.LC0")
gets run through fold_rtx, which recognizes this as a pool constant.
This causes the
known equivalent CONST_DOUBLE 1.0 to be run through force_const_mem,
producing (mem/u/i:DF (symbol_ref/u:SI ("*.LC1"). Which is then tried
in place
of the FLOAT_EXTEND, and selected as valid and cheaper. This all seems
to
be working as expected.
With -fpic, first, fold_rtx doesn't recognize the PIC form as
representing a constant,
so cse_insn never tries forcing the CONST_DOUBLE into memory. Hacking
around
that doesn't help, because force_const_mem doesn't produce the PIC form
of
constant reference, even though we're in PIC mode; we get the same
(mem/u/i:DF (symbol_ref/u:SI ("*.LC1"), which doesn't test as valid in
PIC mode (correctly).
At this point I'm wondering if this is the right place to be attacking
the problem at all.
Advice? Thanks.
gcc-4.0-20050707 is now available
Snapshot gcc-4.0-20050707 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050707/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050707 You'll find: gcc-4.0-20050707.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050707.tar.bz2 C front end and core compiler gcc-ada-4.0-20050707.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050707.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050707.tar.bz2 C++ front end and runtime gcc-java-4.0-20050707.tar.bz2 Java front end and runtime gcc-objc-4.0-20050707.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050707.tar.bz2The GCC testsuite Diffs from 4.0-20050630 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
Re: named address spaces (update)
James E Wilson writes:
>> On Sun, 2005-07-03 at 07:31, Martin Koegler wrote:
>> * need to rewrite recursivly each element of type (which my contain
>> structures, unions, ...) if a address space is set
>> In http://gcc.gnu.org/ml/gcc/2005-04/msg01438.html, this was rated as
>> bad idea.
>
> It is possible I was wrong. Conceptually, this doesn't seem much
> different than existing type qualifiers const/volatile, for which case
> we must already have a solution. Maybe similar treatment will work for
> named address spaces?
>
> Otherwise, these answers all seem very reasonable.
Is there any reasonable solution to the problem which presents itself when
attempting to pass address space qualified pointers as arguments to, or
being returned from, a function; as it seems that unless there's a mechanism
by which "C" can either select overloaded functions as a function of it's
qualified argument and/or return value types, or automatically generate
variants of a given function as may be required based upon it's arguments
memory space designation; it's not clear how named address spaces can be
truly useful if references to them can't be effectively utilized by
functions? (but hopefully I'm misunderstanding something)
For example (for the sake of argument):
ROM const int = 5; // which may require a specific load inst to access.
RAM1 const int = 6; // which may require a different load inst to access.
RAM2 int; // which may require yet a different load/store inst.
RAM2 int* foo(RAM2 int* x, ROM const int* y)
{
*x = *y; // loads from ROM const int* y.
return x;
}
RAM2 int* foo(RAM2 int* x, RAM1 const int* y)
{
*x = *y;// loads from RAM1 cons int* y.
return x;
}
Which represents only 2 of several possible permutations of
ROM RAM1 RAM2 address space argument combinations, which seems both
painful and error prone to have to replicate, and presumes that the
compiler is capable of resolving their selection at compile time, as
may be necessary for the correct code generation of unique address
space argument reference access?
(similar problems already exist for read-only data access if it is desired
to be allocated to an address space which may require unique load/store
access; but worse, as no present mechanism exists to differentiate static
const data from allocated const data argument references for example.)
