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 comp
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 !!
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 whi
>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
[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
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
>
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);
>
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 wo
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 mem
> 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 dai
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
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
reg
> 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
> 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
> 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 reg
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
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
"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
> t
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
>
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
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 o
> 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
> 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
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
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 1
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,
> 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(i
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.
>
>
> F
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
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?
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!
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, r
> 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 _G
33 matches
Mail list logo
