Re: solaris is a secondary platform for gcc-4.4
Benjamin Kosnik wrote: I propose moving sparc-sun-solaris2.10 from primary to secondary on this page: http://gcc.gnu.org/gcc-4.4/criteria.html Thoughts? Please keep it as primary. I try to give my best to help out. I do daily testing on 2.8/2.10. Currently 2.8 is broken. I work in a company where we move very slow with OS updates and we're just in front of the 2.10 update. Thanks Andreas
Re: Test Coverage not on whole execution (gcov)
On Wed, 2008-04-30 at 11:01 +0200, Fabien Baron wrote: > I'm working on a big project in C code, and I want to profile it so I > used gcc with the options -ftest-coverage and -fprofile-arcs, and gcov > to analyze the results. It works very well but on the whole project > and the whole execution !! > My question is : > Is it possible to start and stop profiling/coverage during the program > execution ? If it is how I can do that ? You should not need to compile every object file in the project with those options. Just compile the ones you want to generate coverage data for (of course you will need those options to link). By the way, you really should use --coverage to preserve your sanity. ;-) Cheers, Ben
Re: Should we update __builtin_ia32_palignr?
H.J. Lu wrote: We currently define __builtin_ia32_palignr as long long __builtin_ia32_palignr (long long, long long, int) But it really should be v1di __builtin_ia32_palignr (v1di, v1di, int) Fix it won't affect sources which use intrinsics defined in tmmintrin.h. But it may affect codes which use __builtin_ia32_palignr directly. But I don't think there are many users who use MMX version of gcc SSSE3 builtins directly. Should I submit a patch to change it? Builtins are considered as internal gcc infrastructure, so they can be changed at will as long as published interface (intrinsics in header files) are kept the same. Uros.
Re: solaris is a secondary platform for gcc-4.4
>Benjamin Kosnik <[EMAIL PROTECTED]> writes: > >Given that the set of posted solaris test results for trunk during the >last four months barely requires two hands: > >2008-01 >http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01474.html >http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html >http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html > >2008-02 >http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01519.html > >2008-03 >http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg01093.html >http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00363.html > >2008-04 >(none) > >I propose moving > >sparc-sun-solaris2.10 > >from primary to secondary on this page: > >http://gcc.gnu.org/gcc-4.4/criteria.html > >Thoughts? > >-benjamin Please maintain Solaris 2.10 as a primary platform. Even though I'm just beginning to learn the GCC internals, I would like to contribute to its development as soon as possible. Like the other posters, we have only recently upgraded to 2.10 here. Robert Kiesling --- Ctalk Home Page: http://www.ctalklang.org/.
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
[EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
> Hello,
> I am looking at a testsuite failure (wo_prof_global_var.c) in my
> porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
> during structure optimization. In the code, the structure is split into
> two individual fields (D.2240 and D.2242) and they are allocated
> separately. But the original structure (D.2215) is still allocated, and
> not used afterward. The following RTL-level optimization cannot
> eliminate it.
I think that p is global, and in my understanding right now we have no
whole
program dead code elimination optimization in gcc, but may be I am wrong.
Kenny?
Olga
>
> Cheers,
> Bingfeng Mei
> Broadcom UK
>
> Original C code:
>
> /* { dg-do compile } */
> /* { dg-do run } */
>
> #include
> typedef struct
> {
> int a;
> float b;
> }str_t;
>
> #define N 1000
>
> str_t *p;
>
> int
> main ()
> {
> int i, sum;
>
> p = malloc (N * sizeof (str_t));
> for (i = 0; i < N; i++)
> p[i].a = p[i].b + 1;
>
> for (i = 0; i < N; i++)
> if (p[i].a != p[i].b + 1)
> abort ();
>
> return 0;
> }
>
> .final_cleanup
>
> /*--
> */
> /* { dg-final { scan-ipa-dump "Number of structures to transform is 1"
> "ipa_struct_reorg" } } */
> /* { dg-final { cleanup-ipa-dump "*" } } */
>
>
> ;; Function main (main)
>
> main ()
> {
> int i.43;
> unsigned int D.2245;
> unsigned int D.2243;
> void * D.2242;
> void * D.2240;
> struct struct.0_sub.1 * p.0.4;
> struct struct.0_sub.0 * p.0.3;
> int i;
> void * D.2215;
>
> :
> D.2215 = malloc (8000);
> D.2240 = malloc (4000);
> p.0.3 = (struct struct.0_sub.0 *) D.2240;
> D.2242 = malloc (4000);
> p.0.4 = (struct struct.0_sub.1 *) D.2242;
> p = (struct str_t *) D.2215;
> p.1 = p.0.4;
> p.0 = p.0.3;
> i = 0;
>
> :
> D.2243 = (unsigned int) i << 2;
> (p.0.4 + D.2243)->a = (int) ((p.0.3 + D.2243)->b + 1.0e+0);
> i = i + 1;
> if (i != 1000)
> goto ;
> else
> goto ;
>
> :
> i.43 = 0;
>
> :
> D.2245 = (unsigned int) i.43 << 2;
> if ((float) (p.0.4 + D.2245)->a != (p.0.3 + D.2245)->b + 1.0e+0)
> goto ;
> else
> goto ;
>
> :
> abort ();
>
> :
> i.43 = i.43 + 1;
> if (i.43 != 1000)
> goto ;
> else
> goto ;
>
> :
> return 0;
>
> }
>
>
>
>
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44: > > > > Hello, > > I am looking at a testsuite failure (wo_prof_global_var.c) in my > > porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc > > during structure optimization. In the code, the structure is split into > > two individual fields (D.2240 and D.2242) and they are allocated > > separately. But the original structure (D.2215) is still allocated, and > > not used afterward. The following RTL-level optimization cannot > > eliminate it. > > I think that p is global, and in my understanding right now we have no > whole > program dead code elimination optimization in gcc, but may be I am wrong. You cannot remove p, but if you could split up the allocation for *p then you can for sure remove the original allocation for *p. Otherwise you generated wrong code in the first place, which you certainly did, if p was global. Richard.
RE: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
Olga,
Yes, I agree the "p" is global. But how p is going to be accessed if
another file uses p? D.2215 represents the original "p", but it is not
initialized as "p.0.4" and "p.0.3" do. It won't be correct if other file
tried to use it. Am I right?
Cheers,
Bingfeng
> D.2215 = malloc (8000);
> D.2240 = malloc (4000);
> p.0.3 = (struct struct.0_sub.0 *) D.2240;
> D.2242 = malloc (4000);
> p.0.4 = (struct struct.0_sub.1 *) D.2242;
> p = (struct str_t *) D.2215;
> p.1 = p.0.4;
> p.0 = p.0.3;
-Original Message-
From: Olga Golovanevsky [mailto:[EMAIL PROTECTED]
Sent: 01 May 2008 13:19
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org; Kenneth Zadeck
Subject: Re: Redundant malloc in structure optimization?
(testsuite/gcc.dg/struct/wo_prof_global_var.c)
[EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
> Hello,
> I am looking at a testsuite failure (wo_prof_global_var.c) in my
> porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary
malloc
> during structure optimization. In the code, the structure is split
into
> two individual fields (D.2240 and D.2242) and they are allocated
> separately. But the original structure (D.2215) is still allocated,
and
> not used afterward. The following RTL-level optimization cannot
> eliminate it.
I think that p is global, and in my understanding right now we have no
whole
program dead code elimination optimization in gcc, but may be I am
wrong.
Kenny?
Olga
>
> Cheers,
> Bingfeng Mei
> Broadcom UK
>
> Original C code:
>
> /* { dg-do compile } */
> /* { dg-do run } */
>
> #include
> typedef struct
> {
> int a;
> float b;
> }str_t;
>
> #define N 1000
>
> str_t *p;
>
> int
> main ()
> {
> int i, sum;
>
> p = malloc (N * sizeof (str_t));
> for (i = 0; i < N; i++)
> p[i].a = p[i].b + 1;
>
> for (i = 0; i < N; i++)
> if (p[i].a != p[i].b + 1)
> abort ();
>
> return 0;
> }
>
> .final_cleanup
>
>
/*--
> */
> /* { dg-final { scan-ipa-dump "Number of structures to transform is 1"
> "ipa_struct_reorg" } } */
> /* { dg-final { cleanup-ipa-dump "*" } } */
>
>
> ;; Function main (main)
>
> main ()
> {
> int i.43;
> unsigned int D.2245;
> unsigned int D.2243;
> void * D.2242;
> void * D.2240;
> struct struct.0_sub.1 * p.0.4;
> struct struct.0_sub.0 * p.0.3;
> int i;
> void * D.2215;
>
> :
> D.2215 = malloc (8000);
> D.2240 = malloc (4000);
> p.0.3 = (struct struct.0_sub.0 *) D.2240;
> D.2242 = malloc (4000);
> p.0.4 = (struct struct.0_sub.1 *) D.2242;
> p = (struct str_t *) D.2215;
> p.1 = p.0.4;
> p.0 = p.0.3;
> i = 0;
>
> :
> D.2243 = (unsigned int) i << 2;
> (p.0.4 + D.2243)->a = (int) ((p.0.3 + D.2243)->b + 1.0e+0);
> i = i + 1;
> if (i != 1000)
> goto ;
> else
> goto ;
>
> :
> i.43 = 0;
>
> :
> D.2245 = (unsigned int) i.43 << 2;
> if ((float) (p.0.4 + D.2245)->a != (p.0.3 + D.2245)->b + 1.0e+0)
> goto ;
> else
> goto ;
>
> :
> abort ();
>
> :
> i.43 = i.43 + 1;
> if (i.43 != 1000)
> goto ;
> else
> goto ;
>
> :
> return 0;
>
> }
>
>
>
>
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
Bingfeng Mei wrote:
Olga,
Yes, I agree the "p" is global. But how p is going to be accessed if
another file uses p? D.2215 represents the original "p", but it is not
initialized as "p.0.4" and "p.0.3" do. It won't be correct if other file
tried to use it. Am I right?
Cheers,
Bingfeng
I would be surprised if we could remove a dead malloc (assuming that we
could determine that p was dead, which is another issue). It would not
be hard to add this but p is the hardest problem.
kenny
D.2215 = malloc (8000);
D.2240 = malloc (4000);
p.0.3 = (struct struct.0_sub.0 *) D.2240;
D.2242 = malloc (4000);
p.0.4 = (struct struct.0_sub.1 *) D.2242;
p = (struct str_t *) D.2215;
p.1 = p.0.4;
p.0 = p.0.3;
-Original Message-
From: Olga Golovanevsky [mailto:[EMAIL PROTECTED]
Sent: 01 May 2008 13:19
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org; Kenneth Zadeck
Subject: Re: Redundant malloc in structure optimization?
(testsuite/gcc.dg/struct/wo_prof_global_var.c)
[EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
Hello,
I am looking at a testsuite failure (wo_prof_global_var.c) in my
porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary
malloc
during structure optimization. In the code, the structure is split
into
two individual fields (D.2240 and D.2242) and they are allocated
separately. But the original structure (D.2215) is still allocated,
and
not used afterward. The following RTL-level optimization cannot
eliminate it.
I think that p is global, and in my understanding right now we have no
whole
program dead code elimination optimization in gcc, but may be I am
wrong.
Kenny?
Olga
Cheers,
Bingfeng Mei
Broadcom UK
Original C code:
/* { dg-do compile } */
/* { dg-do run } */
#include
typedef struct
{
int a;
float b;
}str_t;
#define N 1000
str_t *p;
int
main ()
{
int i, sum;
p = malloc (N * sizeof (str_t));
for (i = 0; i < N; i++)
p[i].a = p[i].b + 1;
for (i = 0; i < N; i++)
if (p[i].a != p[i].b + 1)
abort ();
return 0;
}
.final_cleanup
/*--
*/
/* { dg-final { scan-ipa-dump "Number of structures to transform is 1"
"ipa_struct_reorg" } } */
/* { dg-final { cleanup-ipa-dump "*" } } */
;; Function main (main)
main ()
{
int i.43;
unsigned int D.2245;
unsigned int D.2243;
void * D.2242;
void * D.2240;
struct struct.0_sub.1 * p.0.4;
struct struct.0_sub.0 * p.0.3;
int i;
void * D.2215;
:
D.2215 = malloc (8000);
D.2240 = malloc (4000);
p.0.3 = (struct struct.0_sub.0 *) D.2240;
D.2242 = malloc (4000);
p.0.4 = (struct struct.0_sub.1 *) D.2242;
p = (struct str_t *) D.2215;
p.1 = p.0.4;
p.0 = p.0.3;
i = 0;
:
D.2243 = (unsigned int) i << 2;
(p.0.4 + D.2243)->a = (int) ((p.0.3 + D.2243)->b + 1.0e+0);
i = i + 1;
if (i != 1000)
goto ;
else
goto ;
:
i.43 = 0;
:
D.2245 = (unsigned int) i.43 << 2;
if ((float) (p.0.4 + D.2245)->a != (p.0.3 + D.2245)->b + 1.0e+0)
goto ;
else
goto ;
:
abort ();
:
i.43 = i.43 + 1;
if (i.43 != 1000)
goto ;
else
goto ;
:
return 0;
}
RE: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
But how can a function outside of the file use "p" here after
struct_reorg optmization. It isn't correct.
p = malloc (N * sizeof (str_t));
for (i = 0; i < N; i++)
p[i].a = p[i].b + 1;
foo();<-- Assume foo() in another file access p here. It will
either access uninitialized memory chunk (D.2215), or access two split
substructures, then make the first allocated memory useless.
-Original Message-
From: Kenneth Zadeck [mailto:[EMAIL PROTECTED]
Sent: 01 May 2008 15:09
To: Bingfeng Mei
Cc: Olga Golovanevsky; gcc@gcc.gnu.org
Subject: Re: Redundant malloc in structure optimization?
(testsuite/gcc.dg/struct/wo_prof_global_var.c)
Bingfeng Mei wrote:
> Olga,
> Yes, I agree the "p" is global. But how p is going to be accessed if
> another file uses p? D.2215 represents the original "p", but it is
not
> initialized as "p.0.4" and "p.0.3" do. It won't be correct if other
file
> tried to use it. Am I right?
>
> Cheers,
> Bingfeng
>
>
I would be surprised if we could remove a dead malloc (assuming that we
could determine that p was dead, which is another issue). It would not
be hard to add this but p is the hardest problem.
kenny
>> D.2215 = malloc (8000);
>> D.2240 = malloc (4000);
>> p.0.3 = (struct struct.0_sub.0 *) D.2240;
>> D.2242 = malloc (4000);
>> p.0.4 = (struct struct.0_sub.1 *) D.2242;
>> p = (struct str_t *) D.2215;
>> p.1 = p.0.4;
>> p.0 = p.0.3;
>>
>
> -Original Message-
> From: Olga Golovanevsky [mailto:[EMAIL PROTECTED]
> Sent: 01 May 2008 13:19
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Kenneth Zadeck
> Subject: Re: Redundant malloc in structure optimization?
> (testsuite/gcc.dg/struct/wo_prof_global_var.c)
>
>
>
> [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
>
>
>> Hello,
>> I am looking at a testsuite failure (wo_prof_global_var.c) in my
>> porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary
>>
> malloc
>
>> during structure optimization. In the code, the structure is split
>>
> into
>
>> two individual fields (D.2240 and D.2242) and they are allocated
>> separately. But the original structure (D.2215) is still allocated,
>>
> and
>
>> not used afterward. The following RTL-level optimization cannot
>> eliminate it.
>>
>
> I think that p is global, and in my understanding right now we have no
> whole
> program dead code elimination optimization in gcc, but may be I am
> wrong.
>
> Kenny?
>
> Olga
>
>
>> Cheers,
>> Bingfeng Mei
>> Broadcom UK
>>
>> Original C code:
>>
>> /* { dg-do compile } */
>> /* { dg-do run } */
>>
>> #include
>> typedef struct
>> {
>> int a;
>> float b;
>> }str_t;
>>
>> #define N 1000
>>
>> str_t *p;
>>
>> int
>> main ()
>> {
>> int i, sum;
>>
>> p = malloc (N * sizeof (str_t));
>> for (i = 0; i < N; i++)
>> p[i].a = p[i].b + 1;
>>
>> for (i = 0; i < N; i++)
>> if (p[i].a != p[i].b + 1)
>> abort ();
>>
>> return 0;
>> }
>>
>> .final_cleanup
>>
>>
>>
>
/*--
>
>> */
>> /* { dg-final { scan-ipa-dump "Number of structures to transform is
1"
>> "ipa_struct_reorg" } } */
>> /* { dg-final { cleanup-ipa-dump "*" } } */
>>
>>
>> ;; Function main (main)
>>
>> main ()
>> {
>> int i.43;
>> unsigned int D.2245;
>> unsigned int D.2243;
>> void * D.2242;
>> void * D.2240;
>> struct struct.0_sub.1 * p.0.4;
>> struct struct.0_sub.0 * p.0.3;
>> int i;
>> void * D.2215;
>>
>> :
>> D.2215 = malloc (8000);
>> D.2240 = malloc (4000);
>> p.0.3 = (struct struct.0_sub.0 *) D.2240;
>> D.2242 = malloc (4000);
>> p.0.4 = (struct struct.0_sub.1 *) D.2242;
>> p = (struct str_t *) D.2215;
>> p.1 = p.0.4;
>> p.0 = p.0.3;
>> i = 0;
>>
>> :
>> D.2243 = (unsigned int) i << 2;
>> (p.0.4 + D.2243)->a = (int) ((p.0.3 + D.2243)->b + 1.0e+0);
>> i = i + 1;
>> if (i != 1000)
>> goto ;
>> else
>> goto ;
>>
>> :
>> i.43 = 0;
>>
>> :
>> D.2245 = (unsigned int) i.43 << 2;
>> if ((float) (p.0.4 + D.2245)->a != (p.0.3 + D.2245)->b + 1.0e+0)
>> goto ;
>> else
>> goto ;
>>
>> :
>> abort ();
>>
>> :
>> i.43 = i.43 + 1;
>> if (i.43 != 1000)
>> goto ;
>> else
>> goto ;
>>
>> :
>> return 0;
>>
>> }
>>
>>
>>
>>
>>
>
>
>
>
Re: solaris is a secondary platform for gcc-4.4
> Please keep it as primary. I try to give my best to help out. > > I do daily testing on 2.8/2.10. Currently 2.8 is broken. You do seem to be the most active solaris contributor at the moment, and that is encouraging. Thanks for your hard work. Any chance you could post the results of your daily testing of 2.10 to gcc-testresults? That and the transformation of the good intentions in the other replies into actual actions would go a long way towards removing my unease about the current (misleading) classification of solaris. best, benjamin
Re: solaris is a secondary platform for gcc-4.4
On Thu, May 1, 2008 at 3:17 AM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > > Given that the set of posted solaris test results for trunk during the > > last four months barely requires two hands: > >... > > I propose moving > > > > sparc-sun-solaris2.10 > > > > from primary to secondary on this page: > > > > http://gcc.gnu.org/gcc-4.4/criteria.html > > > > Thoughts? We are seeing tests posted, at least, even if the volume isn't what it probably should be for a primary. On Thu, May 01, 2008 at 04:24:28AM +, Dennis Clarke wrote: > Hardly reasonable. > > This may not be a surprise to you but people in datacenters with > Solaris servers tend to move very slowly and cautiously when it comes > to software changes. True, but because they move slowly and cautiously, they often continue with older compilers. > You will get testsuite reports when people get to it. Not before. Not good enough. If people aren't testing the trunk on a daily basis, changes that break the platform won't be noticed for some time, and fixing that platform will be much harder if no one tests for a few months, and other work has been built on top of the change that broke the platform. I'm not saying that I support Benjamin's proposal, but I suggest that it be interpreted as a request, coupled with an implied threat: if you want a platform to continue as a primary platform, there has to be testing, as well as assistance to fix problems when they crop up. If no one tests the trunk on a platform for months at a time, because they "move slowly and cautiously", the quality of that port will seriously decline.
Register interlocks
I have a processor which does not have hardware register interlocks, somewhat like the MIPS I. A register used in one instruction may not be referenced for a certain number of instructions. If I recall correctly, for the MIPS I, the assembler handled inserting nop instructions when it found a register interlock. Are there any targets with register interlock where gcc handles moving instructions between conflicting instructions? Any suggestions on how this might be represented in .md files? It doesn't seem that the pipeline description would seem appropriate. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: libstdc++ svn head broken
> What was the issue? Incorrect (too-lenient) config for OpenMP in other target libraries besides libgomp. I reverted to the too-permissive behavior, which is still wrong but at least won't break stuff. This is now bugzilla http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36101 -benjamin
Re: Register interlocks
> Are there any targets with register interlock where > gcc handles moving instructions between conflicting > instructions? > > Any suggestions on how this might be represented > in .md files? It doesn't seem that the pipeline > description would seem appropriate. This is approximately what ia64 has with bundling. I don't know the exact details, but I believe it has has a md-reorg pass that uses scheduler hooks. Paul
Re: solaris is a secondary platform for gcc-4.4
> We are seeing tests posted, at least, even if the volume isn't what > it probably should be for a primary. sparc-solaris2.10+ has been tested twice on trunk since stage one for gcc-4.4 opened. This is unacceptable, and in the lower bounds even for a secondary target. (All of which have more regular testing than solaris 2.10+). Please note that I have sent private mail to likely solaris testers previous to this asking for testing and have gotten no reply or action. Thus, my public message. > I'm not saying that I support Benjamin's proposal, but I suggest that > it be interpreted as a request, coupled with an implied threat: if > you want a platform to continue as a primary platform, there has to > be testing, as well as assistance to fix problems when they crop up. > If no one tests the trunk on a platform for months at a time, because > they "move slowly and cautiously", the quality of that port will > seriously decline. Exactly. Thanks Joe. -benjamin
Best version of gnat-4.X port to start a port to arm eabi?
Hi! I'm about to lower the gangplanks to get a native gnat on ARM EABI through an unholy succession of cross-compilers, with the object of getting gnat-4.1 4.2 and 4.3 into the new Debian port for ARM EABI. The only arm-targetted gnat I could find is adacore's Windows cross-compiler for xscale (gag retch) but at least that suggests that it's possible, and the Debian ADA person made optimistic noises when I asked, but I thought I'd better consult the oracle first :) I've seen the recommendation about using the same version of gnat as the version you're cross-compiling, and I gather that each version will natively compile later versions ok, but maybe not the other way round, so I'm assuming that I need to use an existing x86-native gnat/gcc to make x86->arm-cross of the same version, then use that canadianly to make arm-native, then use that to build the debian-gnat package or the same and later versions. At the moment I am assuming to start with 4.1 to get all 3, but I know that gcj only works on ARM EABI from 4.3, and C++ still has problems with exceptions (try-catch) on EABI, maybe less so in later versions (?) So, before I set out on the journey, does anyone know of gnat-reasons or ARM EABI-reasons that would make it wiser to start with a later version than 4.1? I confess I know little about Ada except that it has a formal syntax longer than the bible... Thanks M
Re: solaris is a secondary platform for gcc-4.4
Benjamin Kosnik wrote: Please keep it as primary. I try to give my best to help out. I do daily testing on 2.8/2.10. Currently 2.8 is broken. You do seem to be the most active solaris contributor at the moment, and that is encouraging. Thanks for your hard work. Any chance you could post the results of your daily testing of 2.10 to gcc-testresults? That and the transformation of the good intentions in the other replies into actual actions would go a long way towards removing my unease about the current (misleading) classification of solaris. Done. I'll try to post regularly again. I used to complain only when things went wrong :) But I did not realize that the test results have value for others too. Thanks for motivating. Andreas
RE: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
"Bingfeng Mei" <[EMAIL PROTECTED]> wrote on 01/05/2008 16:02:16: > Olga, > Yes, I agree the "p" is global. But how p is going to be accessed if > another file uses p? D.2215 represents the original "p", but it is not > initialized as "p.0.4" and "p.0.3" do. It won't be correct if other file > tried to use it. Am I right? > Yes, the other file cannot use p, it would be incorrect. The tests in gcc.dg/struct are running under specific flags -fwhole-program and -combine, which say the compiler that all program files are given in one compilation line. You can see it in struct-reorg.exp file. Only under this flags struct-reorg optimization is activated. Olga.
Re: Register interlocks
Michael Eager <[EMAIL PROTECTED]> writes: > I have a processor which does not have hardware > register interlocks, somewhat like the MIPS I. > A register used in one instruction may not be > referenced for a certain number of instructions. > > If I recall correctly, for the MIPS I, the assembler > handled inserting nop instructions when it found a > register interlock. > > Are there any targets with register interlock where > gcc handles moving instructions between conflicting > instructions? FWIW, modern GCCs do do this for MIPS I. We wanted to allow GCC to lay out functions itself, rather than relying so much on the assembler. (Overly conservative length estimates can lead to unnecessary long-branch sequences, among other things.) See mips_reorg for the code. As well as the ia64 example Paul mentioned, you might want to look at vr4130_align_insns, which is another subroutine of mips_reorg. These days, you might be better off using the DF machinery. The md_reorg code could look something like: /* Restore the BLOCK_FOR_INSN pointers, which are needed by DF. */ compute_bb_for_insn (); /* Create def-use chains. */ df_chain_add_problem (DF_UD_CHAIN); df_analyze (); ...your stuff here... df_finish_pass (false); free_bb_for_insn (); You can then walk the DF_INSN_USES for each instruction and get a list of their possible definitions. Richard
Re: Best version of gnat-4.X port to start a port to arm eabi?
On Thu, 2008-05-01 at 19:10 +0100, Martin Guy wrote: > Hi! > I'm about to lower the gangplanks to get a native gnat on ARM EABI > through an unholy succession of cross-compilers, with the object of > getting gnat-4.1 4.2 and 4.3 into the new Debian port for ARM EABI. > > The only arm-targetted gnat I could find is adacore's Windows > cross-compiler for xscale (gag retch) but at least that suggests that > it's possible, and the Debian ADA person made optimistic noises when I > asked, but I thought I'd better consult the oracle first :) > I've seen the recommendation about using the same version of gnat as > the version you're cross-compiling, and I gather that each version > will natively compile later versions ok, but maybe not the other way > round, so I'm assuming that I need to use an existing x86-native > gnat/gcc to make x86->arm-cross of the same version, then use that > canadianly to make arm-native, then use that to build the debian-gnat > package or the same and later versions. > > At the moment I am assuming to start with 4.1 to get all 3, but I > know that gcj only works on ARM EABI from 4.3, and C++ still has > problems with exceptions (try-catch) on EABI, maybe less so in later > versions (?) So, before I set out on the journey, does anyone know of > gnat-reasons or ARM EABI-reasons that would make it wiser to start > with a later version than 4.1? Joel Sherrill of RTEMS fame managed to get working Ada for a cross compiler to arm-rtems4.8, for instructions see here: http://www.rtems.com/wiki/index.php/RTEMSAda The main issue for Ada with respect to other GCC languages is the lack of support of "multilibs". I don't know much about multilibs so I can't tell you if this will be a problem for native arm-debian porting. If you're familiar with multilibs I assume Joel would be very happy to resume his efforts to get Ada multilib'ed. As for the version used I would start from trunk and not from older versions, we're in "stage 2" so we're supposed to be not that unstable http://gcc.gnu.org/develop.html As you read, you always have to be careful to bootstrap a native compiler first and then use it exclusively (avoid mixing at all cost the system Ada compiler or an older one). This also has the advantage that you make sure first your base Ada compiler is in working shape before porting it. I don't think you need canadian cross, in the old times there were targets in the Ada Makefile to help moving from a cross to a native compiler. I don't know if they're still around, may be Arnaud or Eric could help you here. I don't know svn much but if you do I assume you could create an ada-arm branch for this porting effort. > I confess I know little about Ada except that it has a formal syntax > longer than the bible... Ah religions :) If you want to compile on a bi-quad Xeon at 3GHz with 16GB of RAM (and many other machines) running debian you can apply for an account on the GCC Compile farm: http://gcc.gnu.org/wiki/CompileFarm Joel and I have accounts there so it might help. I did run once debian-sparc under qemu, I assume debian-arm would do too. Hope this helps, Laurent
Re: solaris is a secondary platform for gcc-4.4
Benjamin Kosnik wrote: We are seeing tests posted, at least, even if the volume isn't what it probably should be for a primary. sparc-solaris2.10+ has been tested twice on trunk since stage one for gcc-4.4 opened. This is unacceptable, and in the lower bounds even for a secondary target. (All of which have more regular testing than solaris 2.10+). It has been tested on a daily basis since years here, on 2.8, and since two months on 2.10. Submitting the results is a bit a pain since I have to copy around the whole stuff. I was not aware that people count on test results. I usually pop up if something goes wrong. If I can I try to fix it myself. If not I talk on IRC and if there is no easy solution I file a PR. Please note that I have sent private mail to likely solaris testers previous to this asking for testing and have gotten no reply or action. Thus, my public message. I wasn't under those recipients. I'm not saying that I support Benjamin's proposal, but I suggest that it be interpreted as a request, coupled with an implied threat: if you want a platform to continue as a primary platform, there has to be testing, as well as assistance to fix problems when they crop up. If no one tests the trunk on a platform for months at a time, because they "move slowly and cautiously", the quality of that port will seriously decline. Exactly. Thanks Joe. See above. For us the platform is important! And I _do_ test! My only shortcoming is that I did not send the results. Andreas
Re: solaris is a secondary platform for gcc-4.4
> I wasn't under those recipients. For the sake of completeness, I wasn't among them either. But I can only offer diligent review of SPARC specific patches these days and help for severe problem reports. -- Eric Botcazou
Re: Best version of gnat-4.X port to start a port to arm eabi?
> I confess I know little about Ada except that it has a formal syntax > longer than the bible... That's probably true. And the C++ one is about 30 or 40% bigger. Arno
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
Richard Guenther <[EMAIL PROTECTED]> wrote on 01/05/2008 16:00:44: > On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]> wrote: > > > > > > [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44: > > > > > > > Hello, > > > I am looking at a testsuite failure (wo_prof_global_var.c) in my > > > porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc > > > during structure optimization. In the code, the structure is split into > > > two individual fields (D.2240 and D.2242) and they are allocated > > > separately. But the original structure (D.2215) is still allocated, and > > > not used afterward. The following RTL-level optimization cannot > > > eliminate it. > > > > I think that p is global, and in my understanding right now we have no > > whole > > program dead code elimination optimization in gcc, but may be I am wrong. > > You cannot remove p, but if you could split up the allocation for *p then you > can for sure remove the original allocation for *p. Otherwise you generated > wrong code in the first place, which you certainly did, if p was global. Again, struct-reorg is a whole program optimization. It explicitly checks the> "whole-program" flag at its gate. It checks the safety of transformation through ipa-type-escape analysis and other escape analysis inside struct-reorg. If it decides it is safe to transform, it replace all variables of specific structure type along with their allocations and accesses. It has obviously enough information to eliminate both a malloc statement and p, even if p is global. But it's question whether it's a right place to do it inside struct-reorg. For example, function level optimizers rely on dce for this matter. Olga > > Richard.
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
On Thu, May 1, 2008 at 10:42 PM, Olga Golovanevsky <[EMAIL PROTECTED]> wrote: > Richard Guenther <[EMAIL PROTECTED]> wrote on 01/05/2008 16:00:44: > > > > > On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]> > wrote: > > > > > > > > > [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44: > > > > > > > > > > Hello, > > > > I am looking at a testsuite failure (wo_prof_global_var.c) in my > > > > porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary > malloc > > > > during structure optimization. In the code, the structure is split > into > > > > two individual fields (D.2240 and D.2242) and they are allocated > > > > separately. But the original structure (D.2215) is still allocated, > and > > > > not used afterward. The following RTL-level optimization cannot > > > > eliminate it. > > > > > > I think that p is global, and in my understanding right now we have no > > > whole > > > program dead code elimination optimization in gcc, but may be I am > wrong. > > > > You cannot remove p, but if you could split up the allocation for *p then > you > > can for sure remove the original allocation for *p. Otherwise you > generated > > wrong code in the first place, which you certainly did, if p was global. > > Again, struct-reorg is a whole program optimization. It explicitly checks > the> > "whole-program" flag at its gate. It checks the safety of transformation > through > ipa-type-escape analysis and other escape analysis inside struct-reorg. If > it > decides it is safe to transform, it replace all variables of specific > structure > type along with their allocations and accesses. It has obviously enough > information > to eliminate both a malloc statement and p, even if p is global. But it's > question > whether it's a right place to do it inside struct-reorg. For example, > function > level optimizers rely on dce for this matter. Sure, a malloc call has side-effects, so a DCE pass cannot just remove it. Only struct-reorg knows that it has replaced all side-effects with others. Richard.
Re: Register interlocks
Richard Sandiford wrote: Michael Eager <[EMAIL PROTECTED]> writes: I have a processor which does not have hardware register interlocks, somewhat like the MIPS I. A register used in one instruction may not be referenced for a certain number of instructions. If I recall correctly, for the MIPS I, the assembler handled inserting nop instructions when it found a register interlock. Are there any targets with register interlock where gcc handles moving instructions between conflicting instructions? FWIW, modern GCCs do do this for MIPS I. We wanted to allow GCC to lay out functions itself, rather than relying so much on the assembler. (Overly conservative length estimates can lead to unnecessary long-branch sequences, among other things.) See mips_reorg for the code. As well as the ia64 example Paul mentioned, you might want to look at vr4130_align_insns, which is another subroutine of mips_reorg. These days, you might be better off using the DF machinery. The md_reorg code could look something like: /* Restore the BLOCK_FOR_INSN pointers, which are needed by DF. */ compute_bb_for_insn (); /* Create def-use chains. */ df_chain_add_problem (DF_UD_CHAIN); df_analyze (); ...your stuff here... df_finish_pass (false); free_bb_for_insn (); You can then walk the DF_INSN_USES for each instruction and get a list of their possible definitions. Richard Thanks Richard and Paul. Good pointers for me to follow. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
> Sure, a malloc call has side-effects, so a DCE pass cannot just remove it.
> Only struct-reorg knows that it has replaced all side-effects with others.
Malloc only has side effects if the result is used.
For example, LLVM will transform
int main(int argc, char** argv){
if(malloc(sizeof(int)) == NULL){ return 0; }
else{ return 1; }
}
into return 1
There is a thread going on in the llvm mailing lists about this right
now, and so far all the text people can find in standards says this is
okay (though I think susv2/POSIX says differently).
Chris says:
"
LLVM should not (and does not, afaik) assume the malloc succeeds in
general.
If LLVM is able to eliminate all users of the malloc assuming the
malloc succeeded (as in this case), then it is safe to assume the malloc
returned success."
>
> Richard.
>
Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
On Thu, May 1, 2008 at 5:10 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > Sure, a malloc call has side-effects, so a DCE pass cannot just remove it.
> > Only struct-reorg knows that it has replaced all side-effects with others.
>
> Malloc only has side effects if the result is used.
>
>
> For example, LLVM will transform
>
>
> int main(int argc, char** argv){
> if(malloc(sizeof(int)) == NULL){ return 0; }
> else{ return 1; }
> }
>
> into return 1
>
> There is a thread going on in the llvm mailing lists about this right
> now, and so far all the text people can find in standards says this is
> okay (though I think susv2/POSIX says differently).
>
> Chris says:
> "
> LLVM should not (and does not, afaik) assume the malloc succeeds in
> general.
>
> If LLVM is able to eliminate all users of the malloc assuming the
> malloc succeeded (as in this case), then it is safe to assume the malloc
> returned success."
BTW, the argument goes something like this:
Transforming malloc into:
our_malloc(int size)
{
if (callsite == the one being compared against null)
{
static char buf[size] __attribute__(maximally_aligned)
return (void *)buf;
}
else
return malloc(size)
}
is legal, and would produce a result that is always non-null.
Thus, if you can eliminate all users of your malloc under the
assumption that malloc returns non-null, you can do so and delete the
malloc.
This also means that things like if (malloc(x) == 0x12345678) would *not* be transformed into "if (1)", only those cases
where the behavior of malloc is checked for nullness.
gcc-4.3-20080501 is now available
Snapshot gcc-4.3-20080501 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080501/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 134868 You'll find: gcc-4.3-20080501.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080501.tar.bz2 C front end and core compiler gcc-ada-4.3-20080501.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080501.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080501.tar.bz2 C++ front end and runtime gcc-java-4.3-20080501.tar.bz2 Java front end and runtime gcc-objc-4.3-20080501.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080501.tar.bz2The GCC testsuite Diffs from 4.3-20080424 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
[tuples] pass_ch is causing bootstrap problems on 64 bit hosts
Zdenek, I can't bootstrap the tuples branch on 64bit hosts because pass_ch is miscompiling stage2/ifcvt.o and stage2/df-scan.o. This causes a segmentation fault while compiling 32/libgcc/bid128_fma.o. By disabling pass_ch I can get past that failure. Would you have time to check it out? Thanks. Diego.
Re: Best version of gnat-4.X port to start a port to arm eabi?
Martin Guy wrote: I confess I know little about Ada except that it has a formal syntax longer than the bible... I hate to tell you, but your Bible must be severely abridged if it has less than 1400 lines!
libstdc++ breakage on powerpc*-linux
Benjamin, Your change for revision 134805, 2008-04-29 Benjamin Kosnik <[EMAIL PROTECTED]> * include/bits/c++config: Remove space between '#' and 'undef' for _GLIBCXX_LONG_DOUBLE_COMPAT. breaks libstdc++ for powerpc*-unknown-linux-gnu on systems where long double is 128 bits, resulting in lots of "undefined reference" errors during linking. The change from "# undef" to "#undef" causes a match in a sed command in libstdc++-v3/include/Makefile, which looks for "^#undef _GLIBCXX_LONG_DOUBLE_COMPAT. Please revert it for now. Janis
Re: libstdc++ breakage on powerpc*-linux
> breaks libstdc++ for powerpc*-unknown-linux-gnu on systems where long
> double is 128 bits, resulting in lots of "undefined reference" errors
> during linking. The change from "# undef" to "#undef" causes a match
> in a sed command in libstdc++-v3/include/Makefile, which looks for
> "^#undef _GLIBCXX_LONG_DOUBLE_COMPAT. Please revert it for now.
Hi Janis. I have been able to reproduce this (finally), and have
checked in the attached patch to fix it.
tested x86_64/linux
tested powerpc64/linux --with-long-double-128
-benjamin
2008-05-01 Benjamin Kosnik <[EMAIL PROTECTED]>
* include/bits/c++config: Revert _GLIBCXX_LONG_DOUBLE_COMPAT change.
Index: include/bits/c++config
===
--- include/bits/c++config (revision 134869)
+++ include/bits/c++config (working copy)
@@ -212,12 +212,11 @@
// XXX GLIBCXX_ABI Deprecated
// Define if compatibility should be provided for -mlong-double-64
-#if defined __cplusplus && defined __LONG_DOUBLE_128__
#undef _GLIBCXX_LONG_DOUBLE_COMPAT
-#endif
// Namespace associations for long double 128 mode.
-#ifdef _GLIBCXX_LONG_DOUBLE_COMPAT
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT && defined __LONG_DOUBLE_128__ \
+ && defined __cplusplus
namespace std
{
inline namespace __gnu_cxx_ldbl128 { }
